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

[Andrew Trick]

On 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.

I agree that the SPEC benchmarks should be fixed first because it’s nice to see SPEC monotonically increasing across LLVM releases.

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.

-Andy

> 
> - 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/255a5307/attachment.html>