<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 12:07 AM, 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="">> So, there is technically no guarantee that you will get an access that<br>
> dominates you.<br>
<br>
</span>I'm unable to come up with a situation where we'd start off with<br>
memory-def dominating memory-uses and getMemoryClobberingAccess (as it<br>
is implemented currently) would return a non-dominating memory access.<br>
Do you have an example where this would happen?<br></blockquote><div><br></div><div>As currently implemented, you are correct, it will not.</div><div>But I have not finished integration into GVN yet.</div><div><br></div><div>Currently, GVN *wants* to know the clobber in all cases so it can see if it can pull the store value out if possible.</div><div><br></div><div>So i am likely to  have to change it (or build a new API) to track and give the clobber if it's a branch above a phi node.</div><div><br></div><div>I can certainly build a new API for this, or i could just make doing what you suggest something it does internally while building.</div><div><br></div><div>But otherwise, my main use case is GVN, and i'm a bit wary of building an API for the rest (because i have no idea what others want :P)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> This is a harder question.  If you do it to every use, you may end up<br>
> spending a bunch of time doing that.<br>
> You are essentially trading build time for query  time.<br>
> If the optimization pass only asks about certain loads, it may not be a good<br>
> tradeoff.<br>
<br>
</span>Makes sense, thanks!<br>
<br>
A related question is if LLVM should cache the result of<br>
`getClobberingMemoryAccess` in the MemoryAccess it computed the result<br>
for (and the other MemoryAccess' it had to look at, transitively).<br>
That seems like a good idea irrespective of how many memory ops were<br>
queried.<br></blockquote><div><br></div><div> Yes, i think doing this makes sense, it'll save densemap lookups.</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></blockquote></div><br></div></div>