Messages in this thread | | | Date | Sat, 31 Dec 2005 00:54:07 +0100 | From | Adrian Bunk <> | Subject | Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers |
| |
On Fri, Dec 30, 2005 at 04:12:22PM -0600, Matt Mackall wrote: > On Wed, Dec 28, 2005 at 08:11:50PM -0800, Andrew Morton wrote: > > If no-forced-inlining makes the kernel smaller then we probably have (yet > > more) incorrect inlining. We should hunt those down and fix them. We did > > quite a lot of this in 2.5.x/2.6.early. Didn't someone have a script which > > would identify which functions are a candidate for uninlining? > > It was a combination of a tool I wrote for -tiny, which added > deprecation warnings to inlines along with a post-processing tool to > count instantiations, nestings, etc., and a post-post-processing tool > written by Denis Vlasenko that guessed at the space usage. > > We cleaned up most of the obvious offenders quite a while ago, but > there's quite a long tail on the usage distribution. It's simply not > worth the trouble to go through the far half of the distribution one > by one to figure out whether inlining makes sense.
The "figure out" task is easy:
There has to be a _very_ good reason for not deleting an inline in a .c file.
inline's in header files are a different topic, but in their case an explicit review would be better since the correct solution is in such cases often to move the code to a .c file (this might even result in additional space savings).
> So I'm in favor of changing our inlining philosophy moving forward. > The world has changed since we started physically marking functions > inline. When we started, basically all arches gained advantage from > heavy inlining due to favorable CPU to memory speed ratios. And the > compiler's automatic inlining was quite primitive. Now most (but not > all!) arches heavily favor out of line code except in fairly critical > locations and the compiler has gotten (just recently) quite a bit > smarter with its inlining. > > So we should really go back to using inline as a hint for 90%+ of > candidate functions (using always.. and no.. for the rest), and using > our compile-time size and arch information to fine-tune the compiler's > decisions as to which hints to take.
I still don't understand why gcc needs any "inline" hints at all except in the cases where we want to force gcc to inline a function.
cu Adrian
--
"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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |