Messages in this thread | | | Date | Sun, 27 Apr 2008 20:22:35 +0300 | From | Adrian Bunk <> | Subject | Re: [PATCH] prepare kconfig inline optimization for all architectures |
| |
On Sun, Apr 27, 2008 at 10:06:41AM -0700, Linus Torvalds wrote: > > > On Sun, 27 Apr 2008, Adrian Bunk wrote: > > > > My opinion on this is still: > > "OPTIMIZE" means "work around bugs in the kernel". > > No. > > It means that > > - gcc used to (long ago) always honor "inline", and we had kernel code > that depended on that in various ways (ie required that there was no > return etc). > > We've been mostly replacing the ones we know about with > "__always_inline", but there may be some that remain. We'll find out, I > guess. > > - gcc was a total and utter piece of horrible crap in the inlining > department, doign insane things and changing their documentation to > match the new behaviour (and some people then claimed that it was > always documented that way). > > It would not inline big functions even when they statically collapsed > to nothing, etc. > > As a result, we really couldn't afford to let gcc make any inlining > decisions, because the compiler was simply *broken*.
I'm looking at it from a different angle, all code in the kernel should follow the following rules [1]: - no functions in .c files should be marked inline - all functions in headers should be static inline - all functions in headers should either be very small or collapse to become very small after inlining
I can simply not see any usecase for a non-forced inline in the kernel, and fixing the kernel should give a superset of the space savings of this "inline optimization".
> Linus
cu Adrian
[1] there might be rare exceptions
--
"Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
| |