<div dir="ltr">It's a one line code change. I'll play with it more later. So far i've found  that on small files it makes no real difference, but on larger code, it is consistently 10-20% faster to do it eagerly. For GVN, anyway. <div><br></div><div>as for absolute time, GVN + MemorySSA also between 0-50% faster on average small files i try it on.<br></div><div><br></div><div>(I tried things from our testsuite)</div><div><br></div><div>For example, one set of C++ files gives me:<br><br></div><div>before:</div><div><div> 0.0018 ( 92.1%)  0.0001 ( 83.5%)  0.0019 ( 91.7%)  0.0019 ( 91.5%)  Global Value Numbering</div><div>  </div><div> 0.0021 ( 92.1%)  0.0006 ( 96.6%)  0.0027 ( 93.1%)  0.0059 ( 96.7%)  Global Value Numbering<br></div><div><br></div><div>after:<br><div>  0.0010 ( 69.1%)  0.0001 ( 69.3%)  0.0011 ( 69.1%)  0.0011 ( 69.3%)  Global Value Numbering</div><div>  0.0002 ( 16.3%)  0.0000 ( 13.7%)  0.0003 ( 16.1%)  0.0003 ( 16.1%)  Memory SSA</div></div><div><br></div><div><div>  0.0009 ( 70.1%)  0.0001 ( 69.2%)  0.0009 ( 70.0%)  0.0009 ( 69.9%)  Global Value Numbering</div><div>  0.0002 ( 16.4%)  0.0000 ( 13.3%)  0.0002 ( 16.2%)  0.0002 ( 16.2%)  Memory SSA</div></div><div><br></div><div><br></div><div>On some files it's also a wash. </div><div>I haven't found anything where it is a regression yet (which is nice :P)<br></div><div><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 11:16 AM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Given this, I'd say let's not worry
about the difference between eager and lazy at this time. Either
is a huge win over where we are and we can come back to that
decision later. Go with whatever is easier to implement.<br>
<br>
(It would be good to confirm that the absolute time on a small
file is also reasonable, but I suspect it will be.)<span class="HOEnZb"><font color="#888888"><br>
<br>
Philip</font></span><div><div class="h5"><br>
<br>
On 02/25/2015 10:32 AM, Daniel Berlin wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">On this file, we get
<div><br>
</div>
<div>Â Â 11.0074 (83.0%) Â 0.1181 ( 49.5%) Â 11.1255 ( 82.6%)
 11.1804 (82.7%)  Total  Global Value Numbering<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>I have files where GVN is 26-30 seconds, but memory ssa +
gvn is still "6-7 seconds"</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Feb 25, 2015 at 10:03 AM,
Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Just for the perspective, how does this compare with
our current GVN times without Memory SSA?
<div>
<div><br>
<br>
On 02/25/2015 09:49 AM, Daniel Berlin wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<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>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>
<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>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
llvm-commits mailing list
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>