<div dir="ltr">So, i would like to see real numbers that say this is going to slow down anything (or speed it up).<br>As I said, if the objection is speed, yes, we should look into that, and if something needs to be done, we should do it.<div><div><br></div><div>We can amortize the cost quite well. It should essentially cost nearly nothing past initial setup cost (it's not harder than the SSA updates we do today, which are not expensive).</div><div><br>The entire plan is actually to amortize the cost.</div><div>Right now, the default pass schedules put things that use memdep mostly in a row.</div><div><br></div><div>At the outset, with a little work, we should have to compute memoryssa twice (once before MLSM/GVN/MemCpyOpt, once before DSE).</div><div>Getting all the way to DSE is harder in the sense that it's a longer way to go to preserve passes.</div><div><br></div><div>But it's also interesting to note that none of these passes preserve memdep today, and the cost of doing memdep queries on every store (as DSE would) with no cache, should be more than the cost of memoryssa building + usage.</div></div><div><br></div><div>It definitely can be made to be so.</div><div>So that part doesn't worry me.</div><div><br></div><div>Shoving this in EarlyCSE, if it's fast enough, seems reasonable at a glance.  In a perfect world, it would be good to preserve it everywhere. I'm not sure, at the beginning, it makes sense to try to preserve it across tons and tons of passes that won't ever use it, but do touch memory heavily.  So i would expect EarlyCSE to end up as another computation point for quite a while.</div><div><br></div><div>That needs to be traded off past how much better/easier/etc it makes EarlyCSE.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 27, 2016 at 1:56 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">gberry added a comment.<br>
<br>
@reames @dberlin Regarding the compile time impact, do you think it would be worth pursuing a change to make EarlyCSE's use of MemorySSA optional?  That way we could avoid using it for early passes EarlyCSE and only use it for later ones, perhaps even influenced by optimization level?  A related aspect of the plan for MemorySSA that I'd like to understand is how well we think we'll be able to amortize the cost of building it by preserving/maintaining it across passes.  Daniel, can you share your thoughts on that?<br>
<br>
<br>
<a href="http://reviews.llvm.org/D19821" rel="noreferrer" target="_blank">http://reviews.llvm.org/D19821</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>