lkml.org 
[lkml]   [2008]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] prepare kconfig inline optimization for all architectures


On Sun, 27 Apr 2008, Adrian Bunk wrote:
>
> What I want instead:
> - we continue to force the compiler to always inline with "inline"
> - we remove the inline's in .c files and make too big functions in
> headers out-of-line

Sure, I can agree with that as a mostly good goal, but you're still
ignoring the fact that nobody should really expect the compiler to always
do a good job at deciding high-level issues.

For example, what's wrong with having "inline" on functions in .c files if
the author thinks they are small enough? He's likely right. Considering
past behaviour, he's quite often more right than the compiler.

Just as an example of this: gcc will often inline even big functions, if
they are called from only one call-site. In fact, ask a compiler guy, and
he'll likely say that that is obviously a good thing.

But ask somebody who debugs the resulting oops reports, and he may well
disagree violently.

In other words, inlining is about much more than pure optimization.

Sometimes it's about forcing it (or not forcing it) for simple correctness
issues when the compiler doesn't understand that the code in question has
specific rules (for example, we sometimes want to *force* certain
functions to be in specific segments).

And sometimes it's about debugging. For the kernel, backtraces posted by
random users are one of the main debug facilities, and unlike many other
projects, it's not reasonable to ask people to recompile with "-O0 -g" to
get better backtraces. The bulk of all reports will come from people who
use precompiled images from a distribution.

And that means that inlining has a *huge* impact on debuggability.

I have vey often cursed gcc inlining some biggish function - who the f*ck
cares if a thousand-instruction function can shave a couple of
instructions of call overhead, when it then causes the call trace to be
really hard to read?

So quite frankly, my preferred optimization would be:

- Heavily discourage gcc from inlining functions that aren't marked
"inline". I suspect it hurts kernel debugging more than many other
projects (because other projects aren't as dependent on the traces)

- I do agree 100% with you that header file functions should be small
(unless they use __builtin_constant_p() or other tricks to guarantee a
much smaller static footprint than dynamic one)

- I also suspect we should have some way for developers to ask fo *hints*
from the compiler, ie instead of having gcc inline on its own by
default, have the people who care about it ask the compiler to warn
about cases where inlining would be a big win.

- Make "inline" mean "you may want to inline this", and "forced_inline"
mean "you *have* to inline this". Ie the "inline" is where the compiler
can make a subtle choice (and we need that, because sometimes
architecture or config options means that the programmer should not
make the choice statically!)
In short, in general I actually wish we'd inline much much less than we
do. And yes, part of that is that we have way too much code in our header
files.

Linus


\
 
 \ /
  Last update: 2008-04-27 20:15    [W:0.323 / U:0.656 seconds]
©2003-2014 Jasper Spaans. Advertise on this site