lkml.org 
[lkml]   [2005]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-12-31 00:56    [W:0.190 / U:0.688 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site