Re: [PATCH] prepare kconfig inline optimization for all architectures

[Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>]

* Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:

> I do obviously think that we're right to move into the direction that 
> "inline" should be a hint. In fact, the biggest issue I have with the 
> new kconfig option is that I think it should probably be 
> unconditional, but I suspect that compiler issues and architecture 
> issues make that not be a good idea.
> 
> It will take time before we've sorted out all the fall-out, because I 
> bet there is still code out there that _should_ use __always_inline, 
> but doesn't.

yeah, we i think had one such issue in x86 (merged upstream prior and 
independently of this feature iirc). We also know that something on 
powerpc doesnt work right out of box with inline being a hint. And 
that's OK and expected - for years we had "inline == always_inline" and 
there was just no force that moved against that. It was in fact 
surprising how well it all worked out on x86 when we reintroduced this 
feature.

btw., another new aspect of this whole area is that a number of major 
distributions now do CONFIG_CC_OPTIMIZE_FOR_SIZE=y in their kernels, and 
that seems to have brought new life into -Os development and with every 
new gcc generation we get denser and denser code generated. It is an 
interesting fact that generating good _small_ code needs a very good 
compiler that understands the code flow very accurately and is able to 
find the smallest possible representation for that.

A side-effect of that is if we do -Os _and_ turn inline into a hint via 
CONFIG_CC_OPTIMIZE_INLINING=y, gcc tends to do a better job than before. 
It cannot just go and inline stuff agressively in stark contrast to the 
-Os goal that was given to it. It still does not do a perfect job though 
- but now at least it has a _chance_ to improve. With always_inline we 
gave gcc no leeway at all.

a second aspect is that there's always the chance that some other 
compiler comes along that does things better than gcc. Again, with 
inline being a necessity we make it impossible for even sane compilers 
to do the right thing.

and a third aspect is that in the current -git kernel we have exactly 
11801 inlines in non-include files. Fighting the constant influx of them 
was a futile act 3 years ago when Arjan and me created this feature for 
the first time and it is futile today. It is a compiler domain problem 
and we should not waste any manpower "fighting" them. Life is too short :)

	Ingo