[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