<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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.)<br>
<br>
Philip<br>
<br>
On 02/25/2015 10:32 AM, Daniel Berlin wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTWVKOrDSUkxxaUAcaEAONJBEsZMg0WKr8NJtP6hxSxwfA@mail.gmail.com"
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 moz-do-not-send="true"
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 class="h5"><br>
<br>
On 02/25/2015 09:49 AM, Daniel Berlin wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>
<a moz-do-not-send="true" 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>
</body>
</html>