Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

[Adrian Bunk <bunk@stusta.de>]

On Mon, Jan 02, 2006 at 03:05:11PM +0100, Ingo Molnar wrote:
> 
> * Adrian Bunk <bunk@stusta.de> wrote:
> 
> > > > > Your uninline patch might be simple, but the safe way would be Arjan's 
> > > > > approach to start removing all the buggy inline's from .c files.
> > > > 
> > > > sure, that's another thing to do, but it's also clear that there's no 
> > > > reason to force inlines in the -Os case.
> > > > 
> > > > There are 22,000+ inline functions in the kernel right now (inlined 
> > > > about a 100,000 times), and we'd have to change _thousands_ of them. 
> > > > They are causing an unjustified code bloat of somewhere around 20-30%. 
> > > > (some of them are very much justified, especially in core kernel code)
> > > 
> > > my patch attacks the top bloaters, and gains about 30k to 40k (depending
> > > on compiler). Gaining the other 300k is going to be a LOT of churn, not
> > > just in amount of work... so to some degree my patch shows that it's a
> > > bit of a hopeless battle.
> > 
> > A quick grep shows at about 10.000 inline's in .c files, and nearly 
> > all of them should be removed.
> > 
> > Yes this is a serious amount of work, but it's an ideal janitorial 
> > task.
> 
> oh, it is certainly an insane amount of janitorial work - which is also 
> precisely why this well-known and seemingly trivial problem has 
> escallated so much!
> 
> the nontrivial thing is that the moment trivial things get widespread, 
> _the mechanism_ needs a change. I.e. the 'widespread inlines' arent the 
> big problem, the big problem is that the widespread inlines _got 
> widespread_. I'm not sure whether i'm being clear enough: think of the 
> 22,000 inlines as a symptom of a deeper problem, not as the problem 
> itself. That is i am trying to get through (to you and to others).

My point goes more into the following direction:
- 10,000 inline's are in .c files
- 12,000 inline's are in .h files

The interesting one's are the latter:
- if they are too big, the smallest solution is to move them to .c files
- it might cause a size _increase_ if some version if gcc will not 
  inline all of them

The latter gives warnings with -Winline, and adding this flag to the 
gloval CFLAGS and analyzing all the warnings (especially with -Os) could 
make my point void.

>...
> what is the 'deeper problem'? I believe it is a combination of two 
> (well-known) things:
> 
>   1) people add 'inline' too easily
>   2) we default to 'always inline'
> 
> problem #1 is very hard to influence, because it's a basic psychology
> issue. Pretty much the only approach to fix this is to educate people.
> But it is hard to change the ways people code, and it's a long-term
> thing with no reasonable expectation of success. So while we can and
> should improve education of this issue (this thread will certainly raise
> awareness of it), we cannot rely on it alone.
>
> i think the only realistic approach is to attack component #2: do not
> default to 'always inline' but default to 'inline if the compiler agrees
> too'. I do think we should default to 'compiler decides' (when using a
> gcc4 compiler), as this also has some obvious advantages:
>
>  - different inlining when compiler optimizes for size not for speed
>
> changing this also means we need to map a few trivial cases where kernel
> code relies on inlining (or relies on non-inlining), but those are
> fortunately easy and mostly well-known.
>...
> so all in one, unless we attack #1 or #2 _with a bigger effective effort 
> than we spend on attacking the symptoms_, we will only achieve a 
> temporary, short-term reprieve.

#1 should definitely be done.

And you do slightly manage to convince me that #2 is a good (additional) 
approach (if -Winline gets added to the global CFLAGS).

> 	Ingo

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/