<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body 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
addFunctionSimplificationPasses(), 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). Are there any
internal issues that would be raised by building an un-optimizaed
version of MemorySSA? I would guess not since there is already an
optimization threshold that prevents MemorySSA from always being
fully optimized.<br>
</p>
<div class="moz-cite-prefix">On 8/25/2016 1:11 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTXGokqjq4r2wPF=QEGrMiKURM-vpM8vyn+Gf05VV7-n0A@mail.gmail.com"
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 moz-do-not-send="true"
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>
<pre class="moz-signature" 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>
</body>
</html>