<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 8, 2016 at 6:40 AM, Anna Thomas <span dir="ltr"><<a href="mailto:anna@azul.com" target="_blank">anna@azul.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
Right now, with the alias analysis change marking invariant.start as readonly, we do not  value forward to invariant.end (which is still readwrite). 
<div><br></div></div></blockquote><div>I'm quite aware, but what later happens is someone says "oh, these are the same", and changes invariant.end, and without a test explicitly breaking, they are likely to think it is okay :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
</div>
<div>Also, the only use of invariant.start is the corresponding </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
</div>
<div><br>
</div>
<div>However, the value forwarding will happen when invariant.end is marked readonly as well. </div>
<div><br>
</div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>foo = invariant.start(a)</div>
<div><stuff><br>
bar = invariant.start(a)</div>
<div>invariant.end (foo) <— was invariant.end(bar) initially</div>
</div>
</div>
</blockquote>
<br>
</div>
<div>Daniel, </div>
<div><br>
</div>
<div>Even with the value forwarding , I think the “invariant set of statements” are not modified. We are not increasing/decreasing the number of “invariant uses" of %a, even though the range of statements within invariant.start and end for foo and
 bar has changed. I think this is true for any other case where the value forwarding modifies invariant.end (since there would be some invariant.start which is still alive, and maintaining the invariance for uses of %a)</div></div></blockquote><div><br></div><div>Well, no.</div><div>If invariant end was readonly, it would value forward past invariant ends, and extend the range in the case it was like this:<br><br></div><div>%a =invariant.start</div><div>...</div><div>invariant.end(%a)</div><div><br></div><div><non-memory affecting instructions><br><br></div><div>%b=invariant.start</div><div>...</div><div>invariant.end(%b)<br><br></div><div>As long as there are no memory writing instructions in the middle, things will believe the two invariant starts produce the same value, and forward it :)<br><br></div><div>GVN is not quite smart enough yet, but it's about to be.</div><div><br></div><div>GCC even has testcases that we both eliminate and PRE pure/const (readonly/readnone) calls.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><br>
</div>
<div>Thanks,</div>
<div>Anna</div><div><div class="h5">
<div><br>
<div>
<blockquote type="cite">
<div>On Aug 6, 2016, at 12:30 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>> wrote:</div>
<br>
<div>
<div dir="ltr">So, this value forwards in a case i hadn't thought about.
<div><br>
</div>
<div>foo = lifetime.start(p)</div>
<div><stuff><br>
bar = lifetime.start(p)</div>
<div>lifetime.end (bar)</div>
<div><br>
</div>
<div>will become</div>
<div>
<div>foo = lifetime.start(p)</div>
<div><stuff><br>
bar = lifetime.start(p)</div>
<div>lifetime.end (foo)</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>I'm not sure the above is even valid, but i found it in Real Live Code(TM).</div>
<div><br>
</div>
<div>Thoughts?<br>
<br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Aug 5, 2016 at 10:15 PM, Anna Thomas <span dir="ltr">
<<a href="mailto:anna@azul.com" target="_blank">anna@azul.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
anna added a comment.<br>
<br>
Changing the code to teach Alias analysis (instead of MDA) about the readonly nature of MDA. All the tests are still valid (and checks remain the same).<br>
getModRefInfo is used by MDA, so the implications on the various passes (GVN, Memcpyopt and DSE) should be the same, it’s just that the code change will be within the same code region where other special cases for llvm.assume and guard intrinsics exist.<br>
<br>
Making the change in alias analysis rather than MDA stemmed from the discussion in llvm-commits mailing list with dberlin and sanjoy.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D23214" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2321<wbr>4</a><br>
<br>
<br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div></div></div>

</blockquote></div><br></div></div>