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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
