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

["Martin J. Bligh" <mbligh@mbligh.org>]

Andrew Morton wrote:

> 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.
>  

It seems odd to me that we're doing this by second-hand effect on
code size ... the objective of making the code smaller is to make it
run faster, right? So ... howcome there are no benchmark results
for this?

M.
-
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/