Re: [PATCH] [3/5] Mark complex bitops.h inlines as __always_inline

[Andi Kleen]

Hi Ingo,

> 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.

To my knowledge the inliner is already fixed. We're just talking about 
old gccs.

Also to be honest I never quite believed in the basic idea of
"hurt users to get someone else to do something" strategies like
you're advocating here.

> 
> 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.

Not inlining bitops qualifies as the later I believe. 

I agree with you if we're talking about random static function
in .c files, but widely used functions in .h files that are 
not expected to change are a little different. The main
reason to not use __always_inline normally is that when people
change the function to contain more code they typically don't 
drop these markers and then it eventually leads to bloat.
But for the bitops style functions I changed here it's not really
expected that they change this way.

Also I don't think adding a few __always_inline for functions which
really need it will hurt maintainability or anything else. In fact
we already have them in a couple of places (e.g. uaccess.h)

> 
> You simply have not made that argument via any numbers here. So i have no 

That's true, I just reacted to Hugh's report. I don't use old
compilers on my own.

-Andi

-- 
ak@xxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/