Re-enable inlining at -O2 at above

[llvmbot]

Bugzilla Link	2272
Resolution	FIXED
Resolved on	May 27, 2008 13:18
Version	trunk
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@asl

Extended Description

We've disabled inlining for llvm-gcc optimization level < 3 for now. There are several reasons for this:

1. This matches gcc behavior so it would not be a surprise to users.
2. Some projects with buggy code, e.g. misuses of inline asm, expect to build correctly at -O2 when inlining is off. We'll encourage users fixed these projects.
3. Some gcc testsuites depend on this -O2 behavior. Some tests would otherwise expose llvm bugs are masked by inlining. We should fix the testsuites.
4. llvm inlining default is too aggressive. At -O2, it should not turn on optimization that will increase code size.

We should re-enable inlining at -O2 but with inlining threshold turned down.

[llvmbot]

No, we shouldn't. -O2 is explicitly documented in gcc not to do inlining, and llvm-gcc should behave the same way. The idea of changing the gcc testsuite is particularly misguided; it is a gcc testsuite and is entitled to depend on documented gcc behavior.

[lattner]

Dale, we have discussed this. GCC DOES DO INLINING at -O2. For example, in C++ mode and with always_inline. Inlining at O2 is the "right thing to do" if it doesn't bloat code. If the documentation claims otherwise, we will change the documentation.

[llvmbot]

The logic to turn on inlining is exactly the logic used by gcc.
You can easily check that gcc does do inlining at -O2 (it is
true that the docs say otherwise). I agree that it would make
sense to only do trivial inlining (inlining functions only used
in one place) and inlining of tiny functions (i.e. reduce the
threshold) at -O2.

[llvmbot]

The flags gcc uses to make inlining decisions seem to be:

flag_inline_trees - whether to do inlining at all
flag_early_inlining - whether to do early inlining
flag_really_no_inline
flag_inline_functions_called_once

[llvmbot]

Jan Hubicka told me on gcc (talking about gcc head):

"At -O2 we do only inlining of functions declared inline or when we think code size will get smaller (inlining very small stuff or stuff called once)
at -O3 we also inline normal functions until given threshold."

He also explained that the -O3 behaviour is controlled by !flag_inline_small_functions (which doesn't exist in gcc-4.2).

[llvmbot]

I have re-enabled inlining at -O2, but with the same
threshold (100) used when optimizing for size:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080512/062578.html

[llvmbot]

I think 100 is too high for both -Os and -O2. We also might want to defeat some of the heuristics in InlineCost that favors certain cases.

[llvmbot]

Rather than playing with the threshold, how about adding an option
-inline-for-size (or something) to the inliner that knows to reduce
the threshold and tone down heuristics?

[llvmbot]

Yes, that's a good idea.