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

    * Linus Torvalds <torvalds@linux-foundation.org> wrote:

    > I do obviously think that we're right to move into the direction that
    > "inline" should be a hint. In fact, the biggest issue I have with the
    > new kconfig option is that I think it should probably be
    > unconditional, but I suspect that compiler issues and architecture
    > issues make that not be a good idea.
    >
    > It will take time before we've sorted out all the fall-out, because I
    > bet there is still code out there that _should_ use __always_inline,
    > but doesn't.

    yeah, we i think had one such issue in x86 (merged upstream prior and
    independently of this feature iirc). We also know that something on
    powerpc doesnt work right out of box with inline being a hint. And
    that's OK and expected - for years we had "inline == always_inline" and
    there was just no force that moved against that. It was in fact
    surprising how well it all worked out on x86 when we reintroduced this
    feature.

    btw., another new aspect of this whole area is that a number of major
    distributions now do CONFIG_CC_OPTIMIZE_FOR_SIZE=y in their kernels, and
    that seems to have brought new life into -Os development and with every
    new gcc generation we get denser and denser code generated. It is an
    interesting fact that generating good _small_ code needs a very good
    compiler that understands the code flow very accurately and is able to
    find the smallest possible representation for that.

    A side-effect of that is if we do -Os _and_ turn inline into a hint via
    CONFIG_CC_OPTIMIZE_INLINING=y, gcc tends to do a better job than before.
    It cannot just go and inline stuff agressively in stark contrast to the
    -Os goal that was given to it. It still does not do a perfect job though
    - but now at least it has a _chance_ to improve. With always_inline we
    gave gcc no leeway at all.

    a second aspect is that there's always the chance that some other
    compiler comes along that does things better than gcc. Again, with
    inline being a necessity we make it impossible for even sane compilers
    to do the right thing.

    and a third aspect is that in the current -git kernel we have exactly
    11801 inlines in non-include files. Fighting the constant influx of them
    was a futile act 3 years ago when Arjan and me created this feature for
    the first time and it is futile today. It is a compiler domain problem
    and we should not waste any manpower "fighting" them. Life is too short :)

    Ingo


    \
     
     \ /
      Last update: 2008-04-27 21:39    [W:0.023 / U:62.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site