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:2.524 / U:0.748 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site