<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Sure, I will provide those. I just wanted to make sure this doesn't
sound like what you know will not work for some reasons I'm not
aware of.<br>
<br>
<div class="moz-cite-prefix">On 14/08/17 20:04, Daniel Berlin wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAF4BwTU6=rx_pL8wawkRiqPa+P4npK8tSBaVoon2ox7tJSrNmQ@mail.gmail.com">
<div dir="ltr">Do you have a formal description of your approach
with examples?
<div>I have a bit of trouble visualizing exactly what your
approach does.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Aug 14, 2017 at 9:58 AM, Ivan
A. Kosarev via llvm-dev <span dir="ltr"><<a
href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello
Steven, Hal and Daniel,<br>
<br>
Thanks a lot for your discussion; it really helps with
summarizing current TBAA issues and ways to resolve them.<br>
<br>
Do you guys know anything of the current status of the
proposed change? Steven, will you please let us know if the
work is in progress and if there is any ETA you can share?<br>
<br>
I'm asking because we are working on an alternative approach
that not only supports accesses to union members, bit
fields, fields of aggregate and union types, but also allows
to represent accesses to aggregates and unions the same way
we do it for scalars so that !tbaa.struct is replaced with
plain !tbaa, meaning TBAA information can be propagated
uniformly regardless of types of accessed objects. As a
consequence, it supports identification of user types
defined in different translation units, even if some of them
are written in C and others are in C++. It also defines a
set of language-neutral formal rules that LLVM codegen
follows to determine whether a given pair of accesses are
allowed to overlap by rules of the input language. As of
today, we know this implementation covers all currently
supported TBAA functionality reflected in the test suites
and to test the new functionality we have SROA improved to
preserve TBAA information.<br>
<br>
The point is, our approach does not try to describe accesses
as (type, offset) pairs and instead represents access
sequences explicitly beginning from the base type followed
by field descriptors, which is what makes the approach so
flexible. TypeBasedAAResult::Aliases() and
MDNode::getMostGenericTBAA() are a bit more complex than
they used to be (they actually use the same internal
function), but rely exclusively on linear scans of access
sequences unless we have a situation when have to check if
one of the accessed types is the type of a member of the
other one, in which case it seems we just have to traverse
through fields recursively no matter what.<br>
<br>
So, I wonder if this or similar approaches have ever been
considered before and what are the cons, if there are any
sounded. Do you think it is worth to consider it now?<br>
<br>
Thanks again,<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
</font></span>
<div class="HOEnZb">
<div class="h5">
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>