<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 24, 2015 at 6:14 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> We don't treat it specially, we actually do exactly what you say.<br>
> We could just pick any argument and end up with the same results. We just<br>
> happen to figure it's most likely to find the version closest to the top of<br>
> the function, which is most likely to be the highest (in the dominator tree)<br>
> version we are trying to reach.<br>
> Otherwise,  we always check to make sure the version of all arguments agree.<br>
<br>
</span>Thanks, this makes sense now.<br></blockquote><div><br></div><div>I'll update it to make this more clear, and i will also just make it pick first argument and see if it really matters in timings.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A related question:  is it correct (and profitable) to do this:<br>
MU->setUseOperand(getClobberingMemoryAccess(MU->getMemoryInst())?<br></blockquote><div><br></div><div>So, there is technically no guarantee that you will get an access that dominates you.</div><div>Otherwise, I can't honestly think of a reason you can't do this assuming you get to a def that does dominates you.</div><div><br></div><div>It's what value numbering is doing anyway.</div><div><br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does it make sense for the MemorySSA pass to apply this transform to a<br>
fixed point, especially at higher optimization levels?<br></blockquote><div><br></div><div>This is a harder question.  If you do it to every use, you may end up spending a bunch of time doing that.</div><div>You are essentially trading build time for query  time.</div><div>If the optimization pass only asks about certain loads, it may not be a good tradeoff.</div><div><br></div><div>GVN happens to look at every load anyway, so it may be good to do for GVN.</div><div><br></div><div>Let me run some before/after numbers.</div><div><br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-- Sanjoy<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> There is one caveat here: We have to skip cyclic phi node arguments (IE<br>
> arguments that lead us back to this phi node). So we can't pick one of those<br>
> to be the argument to check against :)<br>
<br>
><br>
><br>
><br>
><br>
>> It's<br>
>> <a href="http://reviews.llvm.org/D7864" target="_blank">http://reviews.llvm.org/D7864</a><br>
>><br>
>> EMAIL PREFERENCES<br>
>>   <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br></div></div>