lkml.org 
[lkml]   [2009]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-01-07 14:29    [W:0.047 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site