<div dir="ltr">So, to circle back on timings:<br>On my very very large file with lots of functions i use to test GVN timings, <div>doing the clobber checks at build time gives:<br><br></div><div><div> 3.9350 ( 46.4%) 0.0564 ( 36.2%) 3.9915 ( 46.2%) 4.0004 ( 46.2%) Global Value Numbering</div><div> 2.4518 ( 28.9%) 0.0276 ( 17.7%) 2.4795 ( 28.7%) 2.4841 ( 28.7%) Memory SSA</div></div><div><br></div><div><div> 3.8392 ( 46.2%) 0.0620 ( 37.8%) 3.9012 ( 46.0%) 3.9410 ( 46.1%) Global Value Numbering</div><div> 2.4047 ( 28.9%) 0.0319 ( 19.4%) 2.4366 ( 28.8%) 2.4532 ( 28.7%) Memory SSA</div></div><div><div><br></div><div> 3.9762 ( 46.4%) 0.0699 ( 38.7%) 4.0461 ( 46.3%) 4.1086 ( 46.4%) Global Value Numbering</div><div> 2.4720 ( 28.9%) 0.0354 ( 19.6%) 2.5074 ( 28.7%) 2.5295 ( 28.6%) Memory SSA</div></div><div><br></div><div><br></div><div>(As a side note, old GVN took 12 seconds, so yay!)</div><div><br></div><div>Doing it lazily gives:</div><div><br></div><div><div> 5.4972 ( 60.2%) 0.0795 ( 44.3%) 5.5767 ( 59.9%) 5.6230 ( 60.0%) Global Value Numbering</div><div> 1.5262 ( 16.7%) 0.0261 ( 14.5%) 1.5523 ( 16.7%) 1.5618 ( 16.7%) Memory SSA</div><div><br></div><div><div> 5.4386 ( 60.1%) 0.0744 ( 43.1%) 5.5131 ( 59.8%) 5.5430 ( 59.8%) Global Value Numbering</div><div> 1.5087 ( 16.7%) 0.0251 ( 14.5%) 1.5338 ( 16.6%) 1.5413 ( 16.6%) Memory SSA</div></div><div><div> </div><div> 5.4627 ( 59.9%) 0.0865 ( 44.3%) 5.5492 ( 59.5%) 5.6065 ( 59.5%) Global Value Numbering</div><div> 1.5382 ( 16.9%) 0.0296 ( 15.2%) 1.5678 ( 16.8%) 1.5861 ( 16.8%) Memory SSA</div></div><div><br></div><div><br></div><div>So, it definitely makes MemorySSA about 50-60% slower to build.</div><div>However, overall, for GVN, which looks at all loads, it is combined-time 10-15% faster to do it at build time</div><div>(6.2-6.5 seconds vs 6.9-7.0 seconds)<br></div><div><br></div></div><div>So i think it should at least be an option when building memoryssa (though i admit to not knowing if there is an easy way for passes to give options to analysis passes. If it keep it a utility, of course, it's easy)<br></div><div><br></div><div><br></div><div>Thoughts welcome.</div><div><br></div><div><br></div><div>To put these pass times in perspective, something simple like dominator tree construction on this file takes:<br> 0.6060 ( 6.6%) 0.0189 ( 9.7%) 0.6249 ( 6.7%) 0.6323 ( 6.7%) Dominator Tree Construction<br></div><div><br></div><div>So uh, 1.5 seconds to do memoryssa is not that bad :)</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 8:44 AM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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>> 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></span><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><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><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></span><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><font color="#888888"><br>
-- Sanjoy<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div><br></div>