<div dir="ltr"><span style="font-size:12.8px">"I second my case that we should change TBAA instead, such that it handles volatile stuff more conservatively."</span><div class="" style="font-size:12.8px"></div><div><br></div><div>Volatileness and aliasing are different properties.</div><div>It's completely reasonable for TBAA (and other alias analysis) to say two pointers may or may not access different memory.</div><div>It may use any way it feels like to achieve that goal.</div><div><br></div><div>The volatileness of a given access is something the optimizer needs to take into account, not TBAA.</div><div><br></div><div>(and yes, you can get completely inconsistent results between different alias analysis providers, where some will say mustalias and some will say noalias for the same thing).</div><div><br></div><div><br></div><div>TL;DR You should fix LICM or AST, depending on your viewpoint.</div><div>You also have to take into account that TBAA does not obey  transitiveness or other various nice properties,not to mention different AA levels giving inconsistent results.</div><div><br></div><div>Only one result is "most correct" at the language semantic level, but both results are correct at the IR level (ie both noalias and mustalias).  It can use or not use whatever metadata it likes.</div><div><br></div><div><br></div><div>(apropos of nothing, the lack of transitivity/etc in TBAA is one of the reasons effective partitioning schemes for aliasing information don't usually work out :P.  Since AST is basically a partitioning scheme, you are feeling the pain of the edge cases of TBAA)</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 28, 2016 at 5:12 PM, Nuno Lopes via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@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">nlopes added a comment.<br>
<span class=""><br>
In <a href="http://reviews.llvm.org/D16986#359209" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16986#359209</a>, @reames wrote:<br>
<br>
> In <a href="http://reviews.llvm.org/D16986#359180" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16986#359180</a>, @nlopes wrote:<br>
><br>
> > But then store forwarding happens and LICM realizes (or doesn't) that two of the alias sets that were said to be disjoint by TBAA in fact alias.<br>
><br>
><br>
> Can you clarify this point?  AFAIK, LICM does not do store forwarding.  How did store forwarding come into the picture at all?<br>
<br>
<br>
</span>It does.  see here: <a href="http://www.llvm.org/docs/doxygen/html/LICM_8cpp_source.html#l00790" rel="noreferrer" target="_blank">http://www.llvm.org/docs/doxygen/html/LICM_8cpp_source.html#l00790</a><br>
LICM does store forwarding of loop-invariant stores. Plus it moves the store to the loop exit.<br>
So yes, it's this mechanism that is breaking the assumption that an alias set not marked as volatile cannot become volatile later (which it can if UB is exploited, like in this case).<br>
<span class=""><br>
> Also, if we ever discover two pointers mustalias, then by definition they must be the same alias set.  If not, we have constructed *invalid, and incorrect* alias sets.  Oh, I think I see the problem.  You're saying that they're both noalias and mustalias discovered through two different mechanism.  Ouch, ouch, ouch.<br>
<br>
<br>
</span>If add UB to the picture, then 2 pointers that must alias may end up in different alias sets. That's ok; it's just LICM doesn't know how to handle this specific volatile case.<br>
<br>
I second my case that we should change TBAA instead, such that it handles volatile stuff more conservatively.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D16986" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16986</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>