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

[Linus Torvalds <torvalds@osdl.org>]

On Mon, 2 Jan 2006, Krzysztof Halasa wrote:
> 
> For example, I add "inline" for static functions which are only called
> from one place.

That's actually not a good practice. Two reasons:

 - debuggability goes way down. Oops reports give a much nicer call-chain 
   and better locality for uninlined code.

 - Gcc can suck at big functions with lots of local variables. A 
   function call can be _cheaper_ than trying to inline a function, 
   regardless of whether it's called once or many times. I've seen 
   functions that had several silly (and unnecessary) spills suddenly 
   become quite readable when they were separate functions.

   More importantly, the "inline" sticks around. Later on, the function is 
   used for some other place too, and the inline doesn't get removed.

The second "the inline sticks around" case is something that happens to 
helper functions too. They started out as trivial macros in a header file, 
but then they get converted to an inline function because they get more 
complex, and eventually it grows a new hook. Suddenly what used to 
generate two instructions generates ten instructions and a call, and would 
have been much better off being uninlined in a .c file.

So inlines that make sense at one point have a tendency to _not_ make 
sense a year or two later. 

I suspect we'd be best off removing almost all inlines, both from C files 
and headers. There are a few cases where inlining really helps: the 
function really ends up being just a few instructions, and it's really 
just a wrapper around a simpler calling convention or an inline assembly, 
or it's called with constant arguments that are better left off simplified 
at compile-time. Those are the cases where inlining really helps.

(Of course, then there's ia64. Which wants inlining just because..)

		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/