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

[Ingo Molnar <mingo@elte.hu>]

* Andrew Morton <akpm@osdl.org> wrote:

> > > what is the 'deeper problem'? I believe it is a combination of two 
> > > (well-known) things:
> > >
> > >   1) people add 'inline' too easily
> > >   2) we default to 'always inline'
> > 
> > For example, I add "inline" for static functions which are only called
> > from one place.
> > 
> > If I'm able to say "this is static function which is called from one
> > place" I'd do so instead of saying "inline". But omitting the "inline"
> > with hope that some new gcc probably will inline it anyway (on some
> > platform?) doesn't seem like a best idea.
> > 
> > But what _is_ the best idea?
> 
> Just use `inline'.  With gcc-3 it'll be inlined.
> 
> With gcc-4 and Ingo's patch it _might_ be inlined.  And it _might_ be 
> uninlined by the compiler if someone adds a second callsite later on.  
> Maybe.  We just don't know.  That's a problem.  Use of __always_inline 
> will remove this uncertainty.

i agree with your later points, so this is only a minor nit: why is a 
dynamic decision done by the compiler a 'problem' in itself?

It _could_ _become_ a problem if the compiler does it incorrectly, but 
that's so true for just about any other dynamic gcc decision: what 
registers it opts to use in a hotpath, what amount of loop-unrolling it 
does, what machine-ops it choses, how it schedules them, how it reorders 
them, how it generates memory access patterns, etc., etc. Sure, the 
compiler can mess up in _any_ of these dynamic decisions, with possibly 
bad effects to performance, but that by itself doesnt create some magic 
'dynamic inlining is bad' axiom.

In fact, i believe the opposite is true: inlining is arguably best done 
dynamically. Whether gcc makes use of that theoretical opening is 
another question, but my measurements show that gcc4 does a quite good 
job of it. (It certainly does a better job than what we humans did over 
the last 5 years, creating 20,000+ inline markers.)

and even if we let gcc do the inlining, a global -finline-limit=0 
compile-time flag will essentially turn off all 'hinted' inlining done 
by gcc.

> So our options appear to be:
> 
> a) Go fix up stupid inlinings (again) or
> 
> b) Apply Ingo's patch, then go add __always_inline to places which we
>    care about.

note that one of the patches i did (a small one in fact) does exactly 
that, for x86: i marked all things __always_inline that allyesconfig 
needs inlined.

> Either way, we need to go all over the tree. In practice, we'll only 
> bother going over the bits which we most care about (core kernel, core 
> networking, a handful of net and block drivers).  I suspect many of 
> the bad inlining decisions are in poorly-maintained code - we've been 
> pretty careful about this for several years.

yes. And this pretty much supports my point: we should flip the meaning 
of 'inline' around, from 'always inline', to at least: 'inline only if 
gcc thinks so too, if we are optimizing for size'.

and i'd be equally happy with making the flip-around even more agressive 
than my first patch-queue did, to e.g. alias 'inline' to 'nothing':

	#define inline

and to then remove inline from all .c level files (and most .h level 
files) as well - albeit this would punish places that use inline 
judiciously.

Even in this case, it is very likely much easier to re-add inlines to 
the few places that really improve from them (even though they dont need 
it in the __always_inline sense like vsyscalls or kmalloc()), than to 
keep the current 'always inline' logic in place and to hope for a 
gradual reduction of the use of the inline keyword...

	Ingo