Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

[Linus Torvalds <torvalds@osdl.org>]

On Mon, 2 Jan 2006, Jakub Jelinek wrote:
> 
> Where does this certainity come from?  gcc-3.x (as well as 2.x) each had
> its own heuristics which functions should be inlined and which should not.
> inline keyword has always been a hint.

NO IT HAS NOT.

This is total revisionist history by gcc people. It did not use to be a 
hint. If you asked for inlining, you got it unless there was some 
technical reason why gcc couldn't inline it (ie recursive inlining, and 
trampolines and some other issues). End of story. 

So don't fall for the "hint" argument. It's simply not true.

At some point during gcc-3.1, gcc people changed it to be a hint, and did 
so very badly indeed, where functions that really needed inlining (because 
constant propagation made them go away) were not inlined any more. As a 
result, we do

	#define inline   inline __attribute__((always_inline))

in <linux/compiler-gcc3.h> exactly because gcc-3.1 broke so badly.

And nobody sane will argue that we would _ever_ not do that. gcc-3 was 
just too broken. Some architectures (sparc64, MIPS, s390) ended up trying 
to tune the inlining limits by hand (usually making them effectively 
infinitely large), but the basic rule was that gcc-3 inlining was just not 
working.

It may have improved in later gcc-3 versions, and apparently it's getting 
better in gcc-4. And that's the only thing we're discussing: whether to 
let gcc _4_ finally make some inlining decisions.

And people are nervous about it, exactly because the gcc people have 
historically just changed what "inline" means, with little regard for 
real-life code that uses it. And then they have this revisionist agenda, 
trying to change history and claiming that it's always been "just a hint". 
Despite the fact that the gcc manual itself very much said otherwise (I'm 
sure the manuals have been changed too).

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/