Messages in this thread | | | Date | Wed, 7 Jan 2009 14:26:53 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] [3/5] Mark complex bitops.h inlines as __always_inline |
| |
* Andi Kleen <andi@firstfloor.org> wrote:
> > Your patch is wrong because it prevents a good compiler from doing the > > right inlining decisions. > > One or two instruction bitops should be always inlined, not inlining > them always generates much worse code than inlining them. That's easy to > prove just based on code size: the call overhead is larger than the > inlined code.
You are arguing this backwards. Firstly, CONFIG_OPTIMIZE_INLINING is disabled by default. If you enable it, and if CONFIG_OPTIMIZE_INLINING=y creates a larger kernel for you, then either do not enable it - or send numbers so that we can see the true impact of this change.
Yes, simple functions should always be inlined, nobody will argue about that. But GCC's inliner will never be fixed (for the kernel domain at least) if we keep working it around and if we keep micro-managing it.
We work around GCC bugs only if it hurts visibly (and generally if it affects default-enabled features/optimizations): if it can be quantified either via stability/robustness problems or there's excesssive size / efficiency problems.
You simply have not made that argument via any numbers here. So i have no reason to take your patch just yet, unless you provide some clear, documented, measurable benefit.
Ingo
| |