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