Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact

Andi Kleen
2009-01-09T17:06:21Z

On Fri, Jan 09, 2009 at 08:46:20AM -0800, Dirk Hohndel wrote:
> On Fri, 09 Jan 2009 08:34:57 -0800
> "H. Peter Anvin" <hpa@zytor.com> wrote:
> >
> > As far as naming is concerned, gcc effectively supports four levels,
> > which *currently* map onto macros as follows:
> >
> > __always_inline Inline unconditionally
> > inline Inlining hint
> > <nothing> Standard heuristics
> > noinline Uninline unconditionally
> >
> > A lot of noise is being made about the naming of the levels (and I
> > personally believe we should have a different annotation for "inline
> > unconditionally for correctness" and "inline unconditionally for
> > performance", as a documentation issue), but those are the four we
> > get.
>
> Does gcc actually follow the "promise"? If that's the case (and if it's
> considered a bug when it doesn't), then we can get what Linus wants by
> annotating EVERY function with either __always_inline or noinline.

There's also one alternative: gcc's inlining algorithms are extensibly
tunable with --param. We might be able to find a set of numbers that
make it roughly work like we want it by default.

Disadvantage: the whole thing will be compiler version
dependent so we might need to have different numbers
for different compiler versions and it will be an
area that will need constant maintenance in the future.

I'm not sure that's really a good path to walk down to.

Also cc Honza in case he has comments (you might want
to review more of the thread in the archives)

-Andi

--
ak@linux.intel.com