Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 9 Jan 2009, Ingo Molnar wrote:
> 
> Core kernel developers tend to be quite inline-conscious and generally do 
> not believe that making something inline will make it go faster.

Some of us core kernel developers tend to believe that:

 - inlining is supposed to work like macros, and should make the compiler 
   do decisions BASED ON CALL-SITE.

   This is one of the most _common_ reasons for inlining. Making the 
   compiler select static code rather than dynamic code, and using 
   inlining as a nice macro. We can pass in a flag with a constant value, 
   and only the case that matters will be compiled.

It's not about size - or necessarily even performance - at all. It's about 
abstraction, and a way of writing code. 

And the thing is, as long as gcc does what we ask, we can notice when _we_ 
did something wrong. We can say "ok, we should just remove the inline" 
etc. But when gcc then essentially flips a coin, and inlines things we 
don't want to, it dilutes the whole value of inlining - because now gcc 
does things that actually does hurt us.

We get oopses that have a nice symbolic back-trace, and it reports an 
error IN TOTALLY THE WRONG FUNCTION, because gcc "helpfully" inlined 
things to the point that only an expert can realize "oh, the bug was 
actually five hundred lines up, in that other function that was just 
called once, so gcc inlined it even though it is huge".

See? THIS is the problem with gcc heuristics. It's not about quality of 
code, it's about RELIABILITY of code. 

The reason people use C for system programming is because the language is 
a reasonably portable way to get the expected end results WITHOUT the 
compiler making a lot of semantic changes behind your back. 

Inlining is also the wrong thing to do _even_ if it makes code smaller and 
faster if you inline the unlikely case, or inlining causes more live 
variables that cause stack pressure. And we KNOW this happens. Again, I'd 
be much happier if we had a compiler option to just does "do what I _say_, 
dammit", and then we can fix up the mistakes. Because then they are _our_ 
mistakes, not some random compiler version that throws a dice!

			Linus