<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 5:33 PM, Chandler Carruth via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.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">FYI, I ran some initial measurements just for sanity on the test-suite on x86-64:<div><br></div><div>Total stack frame size: 13362520 -> 13365864 (+0.02%)</div><div>Average stack frame size: 581.814 -> 581.96 (+0.02%)</div><div>Average compile time: 5.71178 -> 5.67256 (within noise)</div></div></blockquote><div><br></div><div>Could you share the median stack frame sizes?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Number of functions is exactly the same, so no trivially visible inlining decision changes.</div><div><br></div><div>I've spot checked a few of the functions that had significant change in stack size. One shows a pattern that isn't too surprising in retrospect: this change allows us to hoist more code which causes live ranges to expand and increases spills. Nothing really scary here, and in many ways validates the core premise -- this does actually remove barriers to the mid-level optimizer.</div><div><br></div><div>I've also found one case where stack coloring appears to just fail for no reason: "NArchive::N7z::GetStringForSizeValue(unsigned int)" in 7zHandler.cpp has exactly the same sequence of instructions after the change but 3x larger stack. But this appears to be rare and mostly relating to functions with already small stack sizes. I've filed PR28821 to track this.</div><div><br></div><div>Anyways, while clearly some stuff will need cleaning up, I don't see anything really scary jumping out here.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chandler</div></font></span><div><div class="h5"><div><div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 2, 2016 at 1:02 AM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Seeing no big concerns raised with this direction...<div><br><div class="gmail_quote"></div></div></div><div dir="ltr"><div><div class="gmail_quote"><div dir="ltr">On Sun, Jul 31, 2016 at 9:47 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>1) Add a flag to turn this off.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div><div class="gmail_quote"><div><a href="https://reviews.llvm.org/D23052" target="_blank">https://reviews.llvm.org/D23052</a><br></div><div><br></div><div>Will proceed from there.</div></div></div></div><div dir="ltr"><div><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>2) Run benchmarks with flag to make sure things are actually working.</div><div>3) Change default for the flag, make sure chaos doesn't ensue.</div><div>4) Delete the (quite substantial) complexity associated with this and the flag.</div><div>5) Profit!</div></div><div dir="ltr"><div><br></div><div>-Chandler</div></div></blockquote></div></div></div></blockquote></div></div></div></div></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>