<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 20, 2017 at 9:27 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<p><br>
</p>
<div class="m_-7410282172814824257moz-cite-prefix">On 08/20/2017 11:22 AM, Daniel Berlin
via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Sorry, hit send early.
<div><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Aug 20, 2017 at 9:16 AM,
Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On Sun, Aug
20, 2017 at 8:54 AM, Ivan A. Kosarev via
llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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 Daniel,<span><br>
<br>
> The problem with the way you are trying
to show this is that<br>
> there are many ways to prove no-alias,
and TBAA is one of them.<br>
> The reason i stare at dump files and
debug info is precisely to<br>
> separate the TBAA portion from the
rest.<br>
<br>
</span>
Makes sense to me. However, for a translation
unit like this:<br>
<br>
struct BUF1 { ... };<br>
struct BUF2 { ... };<span><br>
<br>
int foo(int n, struct BUF1* p, struct
BUF2* q) {<br>
for (int i = 0; i < n; i++)<br>
p->b1 += q->b2;<br>
return 0;<br>
}<br>
<br>
</span>
I think we can be sure there are no ways for
the compiler to know that these two accesses
do not overlap, except TBAA.</blockquote>
<div><br>
</div>
</span>
<div>This is definitely false in general.</div>
<div>Again, speaking about GCC, the logic for
whether fields can be accessed is separate from
the logic about whether TBAA says fields can be
accessed.</div>
<div>In some cases the flags to control the logic
are both controlled by fstrict-aliasing, but are
unrelated to tbaa. <br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Our current TBAA combines these two things (field-offset-based
determinations and strictly-type-based rules) into what we call
TBAA. This proposal does likewise. Are there advantages to splitting
them that we should consider?<br><br></div></blockquote><div><br></div><div>Yes.</div><div>GEP has no relation to original field accesses, as you know (IE we allow them to access negative offsets, etc)</div><div>For a lot of these languages, more than the TBAA rules say that you can't just go marching through structures, etc.</div><div><br></div><div>We also have cases TBAA cannot disambiguate but C/C++ says the fields can't overlap. We lack the metadata to correctly say they cannot, because it cannot be inferred from geps.</div><div>(if you search for threads with taewook a while back, you will find some patches and discussion).</div><div><br></div><div><br></div><div>I do not believe the current proposal will solve all of those cases, particularly when the fields are the same type and structures are compatible but they cannot overlap in C/C++ anyway.</div><div><br></div></div></div></div>