<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:52 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">For Andy, or anyone else at Apple looking in to this, this was <<a href="rdar://problem/16368461">rdar://problem/16368461</a>>.</div></blockquote><div><br></div><div>After looking at the performance report, I see that the regressions are not specific to x86. They also show up on armv7 which is running an aggressive SD scheduler. This contradicts my early impression that there was some unlucky interaction between register coalescing and scheduling. We definitely need to understand the issue better before committing.</div><div><br></div><div>-Andy</div><br><blockquote type="cite"><div dir="ltr"><div>On Wed, Apr 9, 2014 at 11:51 AM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:</div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>- Lang.</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><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>> 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>
</div></div></blockquote></div><br></div>
</blockquote></div><br></body></html>