<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 6, 2016 at 1:33 PM, Geoff Berry <span dir="ltr"><<a href="mailto:gberry@codeaurora.org" target="_blank">gberry@codeaurora.org</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">
<p>To follow up on this, I've been experimenting with an alternative
usage of MemorySSA in EarlyCSE and would like to get your opinion
on it. For the pass of EarlyCSE added at the start of
addFunctionSimplificationPasse<wbr>s(), instead of requiring MemorySSA
as an analysis, I have EarlyCSE delay building MemorySSA until it
is needed (i.e. until one of the simple memory generation checks
fails). Furthermore, when it is constructed I added a flag to
turn off the memory use optimization, on the assumption that
EarlyCSE is only going to query a small sub-set of the
loads/stores in the function (I'm still using
getClobberingMemoryAccess() to do the check). I also don't
preserve MemorySSA, side-stepping the issues of having to update
uses/phis when removing stores. Using this approach only misses a
few optimization opportunities and reduces the compile-time impact
to be in the noise for all benchmarks in the testsuite at O2.</p>
<p>Does this seem like a reasonable approach for the near term? It
seems okay to me to miss out on having EarlyCSE preserve MemorySSA
since it seems like it is going to get invalidated pretty soon in
the pipeline anyway (e.g. by JumpThreading). </p></div></blockquote><div>I don't think we should avoid preserving stuff because the current default pipeline does things a certain way.</div><div>Besides the fact that others have different pipelines, the way things get preserved everywhere is piecewise :)</div><div><br></div><div>i can't imagine the calls to do the updating make it slow :)</div><div>Only the optimizing during updating makes it slow.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><p>Are there any
internal issues that would be raised by building an un-optimizaed
version of MemorySSA? </p></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><p> I would guess not since there is already an
optimization threshold that prevents MemorySSA from always being
fully optimized.<br></p></div></blockquote><div>I'm still opposed to playing this game of not use optimizing until any data shows it actually matters for real.</div><div>So far i don't think the cost we are paying makes it worth doing that.</div><div><br></div><div>This is because it is *significantly* more expensive (at least 2x, sometimes 10x) once *anything* cumulatively queries even half the stores or loads total (without being invalidated). That time just shows up in the time passes differently, so people think it is cheaper, but it's actually really expensive. In practice, all of the things we have tried to make lazy, and then get used by everything, are significantly slow compared to being eager (basicaa, LVI, etc). I would much rather us avoid that trap :)</div><div><br></div><div>Even eagerly use-optimizing and then reoptimizing only the changed pieces is significantly faster :)</div><div>Then again, my views above are colored by the thought that the numbers you had seemed fine to me as-is.<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"><div bgcolor="#FFFFFF" text="#000000"><p>
</p><div><div class="h5">
<div>On 8/25/2016 1:11 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Aug 25, 2016 at 8:36 AM,
Geoff Berry <span dir="ltr"><<a href="mailto:gberry@codeaurora.org" target="_blank">gberry@codeaurora.org</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">
<p>Sounds good. I'll go ahead and check in what I have
now (since it is NFC) and we can proceed from there.</p>
<p>I'm currently trying out an approach where upon
removing a store I eagerly re-optimize phis, but just
mark uses as dirty, then only re-compute the clobber
for dirty uses if they come up in a
isSameMemGeneration query or at the end of the pass,
which is sort of a hybrid of the two approaches you
described.<br>
</p>
</div>
</blockquote>
<div>Okay.</div>
<div>Internally, I'm going to add an optimized bit that gets
reset, and make the default walker only rewalk uses that
are not optimized (and optimize them).</div>
<div><br>
</div>
<div>That way if you just call getClobberingMemoryAccess,
you'd get the right answer all the time and it would only
be expensive when it needs to actually be recomputed.</div>
<div><br>
</div>
<div>Note that this will be imperfect.</div>
<div>It relies on not having indirect uses (which use
optimization initially guarantees).</div>
<div><br>
</div>
<div>That is, it relies on a given store having all of the
loads that use it, have it as the clobbering definition.</div>
<div><br>
</div>
<div>Otherwise, when you remove/RAUW the store, you will not
invalidate the full set of uses.</div>
<div><br>
</div>
<div><br>
</div>
<div>I will also make a batch updater that can do phi
insertion and redo use optimization for pieces of
memoryssa.</div>
<div><br>
</div>
<div>--Dan<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div></div><span class=""><pre cols="72">--
Geoff Berry
Employee of Qualcomm Datacenter Technologies, Inc.
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.</pre>
</span></div>
</blockquote></div><br></div></div>