<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 class="">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. </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 can depend on more than just TBAA, including alignment rules, etc.</div></div></div></div></blockquote><div><br></div><div>You definitely may be able to come up with examples where only tbaa *should* be active, but i don't think it's really a safe way to go about testing assumptions about TBAA.</div><div>For example, it also assumes no bugs in the other methods of analysis, which is defintitely not a safe assumption :)</div><div><br></div><div>If you only care about the *end result* (IE whether it's allow to say the accesses overlap) it is generally going to be okay, but again, this assumes no bug in any implementation</div><div><br></div><div>If you want to test tbaa specific things for real, you'd have to print the tbaa trees and results as gcc sees them, for example.</div><div>That's really the only way to be sure.</div><div><br></div><div><br></div><div><br></div></div></div></div></div>