<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 11, 2016 at 10:18 AM, Teresa Johnson <span dir="ltr"><<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">tejohnson added a comment.<br>
<span><br>
In <a href="http://reviews.llvm.org/D15537#397257" rel="noreferrer" target="_blank">http://reviews.llvm.org/D15537#397257</a>, @davidxl wrote:<br>
<br>
> yes -- MemSSA will get there.  Short term workaround might also be needed :)<br>
<br>
<br>
</span>I think we need a stopgap fix for this non-linear compile time issue. </blockquote><div><br></div><div>Again, my main concern is that literally every other "stopgap" fix around memory optimization issues has not been a stopgap.</div><div>There is no other way to put it.</div><div>These things have compounded *very* badly over time.  </div><div>I'm not approving yet another compile time knob for another N^2/N^3 pass that we know how to fix the right way.<br></div><div><div>(In part because i am the one who ends up having to fix it later :P) </div><div><br></div><div>We have to hold the line somewhere. This is where i am holding it. If you want to get someone else to approve it, i won't stand in the way.</div><div> <br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I don't think waiting until it is reimplemented to use MemorySSA is a good strategy given the extreme compile time issues,</blockquote><div><br></div><div>Which, for the most part, only occur in new build modes or very artificial code.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> and I can't even find a switch to disable this pass.<br></blockquote><div><br></div><div>This is definitely a problem.  Honestly, at this point, i would rather see us disable the pass entirely with a large number of stores than add yet another knob to control other things (like how many instructions it visits).</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
BTW, the author had provided a test case on the mailing list (there are two threads for this patch):<br>
<br>
<a href="http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160201/330335.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160201/330335.html</a></blockquote><div><br></div><div>If you look at the testcase, it is *very* artificial :)<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
<br>
<br>
<a href="http://reviews.llvm.org/D15537" rel="noreferrer" target="_blank">http://reviews.llvm.org/D15537</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>