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

[Andrew Morton <akpm@osdl.org>]

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/