[llvm] r204076 - Use range metadata instead of introducing selects.

[Andrew Trick]

On Apr 9, 2014, at 11:52 AM, Lang Hames <lhames at gmail.com> wrote:

> For Andy, or anyone else at Apple looking in to this, this was <rdar://problem/16368461>.

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.

-Andy

> On Wed, Apr 9, 2014 at 11:51 AM, Lang Hames <lhames at gmail.com> wrote:
> Hi Guys,
> 
> 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:
> 
> "12% slower on MultiSource/Benchmarks/FreeBench/analyzer/analyze"
> "9% slower MultiSource/Benchmarks/sim/sim"
> "4.5% slower on External/SPEC/CINT2000/164_gzip/164_gzip"
> "7% slower on External/SPEC/CINT2006/462_libquantum/462_libquantum"
> 
> 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.
> 
> - Lang.
> 
> 
> 
> On Wed, Apr 9, 2014 at 2:59 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> > Ok. If we know that the number instructions before coalescing is
> > less-or-equal and the spill count is greater in each of the regressions,
> > that enough of a clue to pin it on coalescing/scheduling/regalloc.
> >
> > I don’t like to prevent the right thing at IR level just because downstream
> > codegen happens to make bad decisions.
> 
> +1
> 
> Dan, can you commit it again and open a bug about the codegen issue?
> 
> Thanks,
> Rafael
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140409/4f17ac3c/attachment.html>