[llvm-commits] [test-suite] r160413 - in /test-suite/trunk/SingleSource/Benchmarks/Misc: matmul_f64_4x4.c matmul_f64_4x4.reference_output

Evan Cheng evan.cheng at apple.com
Wed Jul 18 20:53:56 PDT 2012


On Jul 18, 2012, at 3:20 PM, Jakob Stoklund Olesen wrote:

> 
> On Jul 18, 2012, at 1:40 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
>> Ok, I got confused by the comment and your explanation at first, but reading the bug: with this wrapper, an extra optimization occurs that actually turns out to hurt ARM codegen. That's what the PR is about, making this "extra" optimization not actual hurt ARM codegen, right?
> 
> That's right. Dan says SROA shouldn't be doing this in the first place, but we also should be able to handle it in codegen when it does happen.

CodeGen should be able to coupe with anything the optimizer decides to do. But it's not always possible to recover the performance loss. Dan is right, this should be fixed in SROA.

Evan

> 
>> So what is the comment in the code about? Is this extra optimization actually helping on other platforms, making the wrapper a positive effect on performance? Or is the comment just inaccurate?
> 
> Oh, you means the sense of 'optimizations' where the code actually goes faster afterwards? Yes, that is inaccurate ;-)
> 
> Maybe 'transformations' is better.
> 
>> If adding this wrapper actually improves performance (with a fixed PR13392 or on a platform where that doesn't happen), then *that* is the inliner bug I'd like to know about. =]
> 
> The wrapper is just there to expose the issue. It wasn't originally added to improve performance.
> 
> /jakob
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list