lkml.org 
[lkml]   [2006]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 00/2] improve .text size on gcc 4.0 and newer compilers
    Adrian Bunk <bunk@stusta.de> wrote:
    >
    > On Mon, Jan 02, 2006 at 11:37:21AM +0100, Ingo Molnar wrote:
    > >...
    > > to say it loud and clear again: our current way of handling inlines is
    > > _FUNDAMENTALLY BROKEN_. To me this means that fundamental changes are
    > > needed for the _mechanics_ and meaning of inlines. We default to 'always
    > > inline' which has a current information to noise ratio of 1:10 perhaps.
    > > My patch changes the mechanics and meaning of inlines, and pretty much
    > > anything else but a change to the meaning of inlines will still result
    > > in the same scenario occuring over and over again.
    >
    > Let's emphasize what we both agree on:
    > It is _FUNDAMENTALLY BROKEN_ that too much code is marked as
    > 'always inline'.
    >
    > We only disagree on how to achieve an improvement.
    >

    The best approach is to manually review and fix up all the inline statements.

    We cannot just delete them all, because that would cause performance loss
    for well-chosen inlinings when using gcc-3.

    I'd be reluctant to trust gcc-4 to do the right thing in all cases. If the
    compiler fails to inline functions in certain critical cases we'll suffer
    some performance loss and the source of that performance loss will be
    utterly obscure.

    If someone types `inline' into a piece of code then we want to inline the
    function, dammit. The fact that lots of people typed `inline' when they
    shouldn't have is not a good argument for defeating (or adding uncertainty
    to) manual inlining in well-developed and well-maintained code.

    All those squillions of bogus inlines which you've identified are probably
    mainly in code we just don't care about much. We shouldn't penalise
    well-maintained code because of legacy problems in less well-maintained
    code.
    -
    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/

    \
     
     \ /
      Last update: 2006-01-02 19:34    [W:4.262 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site