
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Apr 9, 2014, at 11:51 AM, Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Guys,<div><br></div><div>I picked on fourinarow because it was the largest regression due to this patch, but it wasn't the only one. There were about 30 test-suite regressions according to our testers, including:</div>

<div><br></div><div>"12% slower on MultiSource/Benchmarks/FreeBench/analyzer/analyze"</div><div>"9% slower MultiSource/Benchmarks/sim/sim"</div><div>"4.5% slower on External/SPEC/CINT2000/164_gzip/164_gzip"</div>

<div>"7% slower on External/SPEC/CINT2006/462_libquantum/462_libquantum"</div><div><br></div><div>We should do the right thing at IR time, but before this patch goes back in we need to identify and fix whatever is going wrong in CodeGen, or verify that it's no longer a problem. If this goes back in and the regressions re-appear we'll just need to revert it again.</div></div></blockquote><div><br></div>I agree that the SPEC benchmarks should be fixed first because it’s nice to see SPEC monotonically increasing across LLVM releases.</div><div><br></div><div>On FreeBench and sim, I would say the same thing as fourinarow. If it can be shown that Dan’s patch generates better code by all measures, but we latter end up spilling in some unfortunate way, file a codegen bug AND commit. I’m actually in favor of exposing codegen performance issues in the LLVM test suite so the next person working on similar issues can measure their improvements. Otherwise the chance of ever getting it fixed is very slim.</div><div><br></div><div>-Andy</div><div><br><blockquote type="cite"><div dir="ltr">

<div><br></div><div>- Lang.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 9, 2014 at 2:59 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> Ok. If we know that the number instructions before coalescing is<br>

> less-or-equal and the spill count is greater in each of the regressions,<br>

> that enough of a clue to pin it on coalescing/scheduling/regalloc.<br>

><br>

> I don’t like to prevent the right thing at IR level just because downstream<br>

> codegen happens to make bad decisions.<br>

<br>

</div>+1<br>

<br>

Dan, can you commit it again and open a bug about the codegen issue?<br>

<br>

Thanks,<br>

Rafael<br>

</blockquote></div><br></div>

</blockquote></div><br></body></html>