<div dir="ltr">In particular, i feel this way because GVN should already get your case without this.<div>The fact that it doesn't is an issue with AA.</div><div>Working around it like this only fixes GVN's ability to optimize this.  There will be plenty of cases something *else* could  eliminate code like that will not be able to<br>Fixing AA fixes it for everyone (and doesn't require pass-specific workarounds).</div><div><br></div><div>So i'd like to understand what is going wrong in AA before we start trying to hack around it in GVN.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 12, 2018 at 9:08 AM, Daniel Berlin via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">dberlin added a comment.<br>
<br>
So this looks like a really weird optimization to avoid AA being broken.<br>
As you say, the code it inserts will be fixed up later (and you are taking an O(1) function and making it O(N).<br>
We should just fix AA.<br>
<br>
It should see no difference between the two.<br>
If we really can't fix AA, i'd like to understand why before we go this route.<br>
Because we shouldnt' be working around these problems this way.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D44160" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D44160</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>