Re: [patch] x86: phase out forced inlining

Sam Ravnborg
2008-03-03T14:56:13Z

Hi Ingo.

> Subject: x86: phase out forced inlining

Any particular reason you made the patch x86 specific?

It is preferred to gain this size decrease for other arch too
and having a single definiton of OPTIMIZE_FOR_SIZE
would help here.

We have this for other gcc options already.

> +config OPTIMIZE_INLINING

Other (not all) config options that deal with gcc behaviour are
named CC_*. But they mostly impact gcc options.
CC_OPTIMIZE_INLINING would match the naming of CC_OPTIMIZE_SIZE,
except in the latter OPTIMIZE refer to the -O option.

CC_DEFAULT_INLINE may give the right associations?

> + bool "Allow gcc to uninline functions marked 'inline'"
> + default y
> + help
> + This option determines if the kernel forces gcc to inline the functions
> + developers have marked 'inline'. Doing so takes away freedom from gcc to
> + do what it thinks is best, which is desirable for the gcc 3.x series of
> + compilers. The gcc 4.x series have a rewritten inlining algorithm and
> + disabling this option will generate a smaller kernel there. Hopefully
> + this algorithm is so good that allowing gcc4 to make the decision can
> + become the default in the future, until then this option is there to
> + test gcc for this.

Would it be worth here to mention that stuff that really
needs inlining should use __always_inle and not inline?

> + */
> +#ifndef CONFIG_OPTIMIZE_INLINING
> +# define inline inline __attribute__((always_inline))
> +# define __inline__ __inline__ __attribute__((always_inline))
> +# define __inline __inline __attribute__((always_inline))
> +#endif

A quick google did not tell me the difference between inline, __inline, __inline__.
But it turned out the december 2005 thread where there was a lenghty discussion about
trusting gcc with respect to inlining.
It is not the subject of this patch but I just wondered why we need all these variants.

Sam