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

Linus Torvalds
2006-01-02T19:45:04Z

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