<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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 class=""><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 class=""><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><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.</div><div><br></div><div>Even if you have tried to place the fields at the same offset, as you have, whether it can disambiguate the accesses is what happens depends on the language </div><div><br></div><div>But it's definitely the case that, given the above, unless the field layout is identical, </div></div></div></div>