Disable gcc inliner

[lattner]

Bugzilla Link	3232
Resolution	FIXED
Resolved on	Feb 08, 2009 04:33
Version	2.2
OS	All
Depends On	#2725 llvm/llvm-bugzilla-archive#3290
Blocks	#3371
CC	@asl,@efriedma-quic

Extended Description

llvm-gcc is running the GCC tree-inliner as well as the llvm inliner. This has certain advantages, but also brings certain problems. For example, it seriously unrolls code like this C++ code (which is a huge code size problem and not really a win):

#include <stdio.h>
template< typename X >
inline X factorial( X n ) {
if ( n )
return n * factorial(n - 1);
return 1;
}
int main(){
double x = factorial( ( double )19 );
printf( "factorial( (double)19 ): %f\n", x );
return 0;
}

$ llvm-gcc main.opt.cpp -S -o - -emit-llvm -O3 -mllvm -disable-llvm-optzns

Which is basically horrible. Turning off the GCC inliner would also fix Bug 2999, but we have to watch out for 2353.

-Chris

[lattner]

*** Bug #3483 has been marked as a duplicate of this bug. ***

[lattner]

Duncan, did your patch to "reenable the gcc inliner" somehow make it more insane than it was before? Or is this an effect from going from 4.0 to 4.2?

[llvmbot]

We don't run the early gcc inliner and do run the full gcc inliner.
The reason was that only the full inliner would inline "always inline"
functions. But now that LLVM supports "always inline" directly, maybe
we should switch that round, and only run the early gcc inliner (which
I think is more conservative than the full one). Of course maybe it
is no longer useful to run the gcc inliner at all anymore, but that
requires some testing to determine.

[lattner]

the only major problem i see (in theory) with disabling the GCC inliner is that we probably don't do NRVO and other optimizations (copy copy ctor elision) that the C++ Front-end + inliner do. Aside from that minor technical detail :), it should be no problem, just an issue of doing it and measuring the impact.

[llvmbot]

I've switched gcc's full inliner off, and turned on the
early inliner instead. With this change gcc no longer
horribly unrolls the C++ testcase. Hopefully this will
not slow down webkit and friends (but it might). On the
other hand, this does cause a testsuite failure due to
alloca's not being eliminated (there doesn't seem to be
anything stopping them being removed, but for some reason
sroa doesn't do it): 2008-03-24-BitField-And-Alloca.c
Hopefully Chris can take a look, because sroa is too much
for me :)

[lattner]

I'll take a look at FrontendC/2008-03-24-BitField-And-Alloca.c when I get a chance, it might be a few days though.

[llvmbot]

testcase .ll
Here's the bitcode generated for 2008-03-24-BitField-And-Alloca.c on
x86-32. The test fails because the allocas are not all eliminated.

[efriedma-quic]

Created an attachment (id=2360) [details]
testcase .ll

Here's the bitcode generated for 2008-03-24-BitField-And-Alloca.c on
x86-32. The test fails because the allocas are not all eliminated.

That output looks suspicious: the "store i64 %key_token2, i64* %2, align 8" assumes more alignment than it can legitimately assume.

[llvmbot]

WebKit and some of the internal benchmarks have regressed. I'm taking a look.

[llvmbot]

In cpp it's clear llvm's inliner is less aggressive than gcc's. It may be as simple as increasing the aggression of llvm's inliner.

[lattner]

I think that is probably a good idea (and worth some experimentation!). Previously it was turned down pretty low because it was interacting with the GCC inliner. With that variable gone we can do some more precise measurements and experimentation.

[llvmbot]

OK, I will experiment with cpp and we can go from there....

[llvmbot]

A setting of -inline-threshold=350 gives good results for cpp, i.e. the same as it was before Duncan's patch. This is a sweet spot; 325 and 375 are both considerably worse.
The way this is benchmarked is one file at a time rather than running IPO. This is most comparable to gcc (which was the point; the benchmark was set up originally to isolate a different problem), but may not scale up. I'll try it on some other things.

It appears llvm's inliner does not inline more than one level deep (i.e. new callsites that appear as a result of one inline are not considered for inlining),
// Scan through and identify all call sites ahead of time so that we only
// inline call sites in the original functions, not call sites that result
// from inlining other functions.
while I know gcc's inliner does. (You can run llvm's inliner more than once, I suppose, but that doesn't do the same thing as gcc's algorithm.) It's easy to construct cases where gcc's way is better. Of course doing that requires considerable bookkeeping and deciding when to stop is a problem...

[lattner]

Ah, Dale that is very interesting. Can you come up with an example of where that would be beneficial?

-Chris

[llvmbot]

I see, it's bottom up, that does handle things pretty well. I know gcc's algorithm was mainly important (and it is quite important in some cases) where you had information about which calls were more likely to be executed, as from profiling (and even that is more important on machines with a reasonable number of registers than on x86). For example
a() { b(); .... b(); }
b() { c(); }
c() { big }
If we know one of the calls to b is not going to get executed often and the other is, and there are no calls to b from anywhere else, we want to inline b and c at the hot call, and neither the other call to b nor the call to c within the original b.
Lacking profile info I don't have a case where it's important. One may turn up:)