[llvm-commits] [llvm-gcc-4.2] r63123 - in /llvm-gcc-4.2/branches/Apple/Dib/gcc: cgraphunit.c ipa-inline.c passes.c tree-pass.h

Dale Johannesen dalej at apple.com
Tue Jan 27 13:09:09 PST 2009


On Jan 27, 2009, at 1:03 PMPST, Chris Lattner wrote:

> On Jan 27, 2009, at 12:57 PM, Dale Johannesen wrote:
>>>> Is this some general performance issue, or just that some specific
>>>> code that's been extensively tuned to work well with gcc's inliner
>>>> doesn't work as well now?  The latter would be expected
>>>
>>> I considered it a general performance issue that just happen to be
>>> exposed by a particular test case.
>>
>> Do you have evidence for this?   I've looked at it quite a bit, and
>> concluded that llvm-gcc's inliner does less inlining on average than
>> gcc's, but that this is not, in general, a problem:  in other words,
>> benchmarks that are better and worse are about equal in number.
>> (And performance being roughly equal, smaller code size is to be
>> preferred.)
>
> I can give two easy examples.  1: SROA is not promoting aggregates in
> all cases that it could.  This is particularly a problem for the "by
> value struct passing" stuff in the ABI lowering code of llvmgcc.  2:
> llvm's optimizer doesn't do C++ copy constructor elision.
>
> Both of these mean that if the GCC inliner runs before tree -> LLVM,
> that you'll get the optimizations and performance will be good.
> Running tree -> LLVM before the LLVM inliner will prevent these from
> happening.

Ah OK, these are not issues with the inliner itself but with other  
missing optimizations.  I read Evan's message as saying this was a  
general issue with the inliner, but I see he didn't say that.  Going  
away now.




More information about the llvm-commits mailing list