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

Tim Schmielau
2005-12-30T02:03:27Z

On Thu, 29 Dec 2005, Arjan van de Ven wrote:

> Some data from an x86-64 allyesconfig build.

Thanks for the table. This certainly is a good starting point to find
valid candidates for uninlining.

> Below is a *rough* estimate of savings that could be achieved by
> uninlining specific functions. The estimate is rough in the sense that
> it assumes
> that no "trick" allows the uninlined version to be significantly smaller
> than the inlined version, which for certain functions is not a valid
> assumption (kmalloc comes to mind as an obvious one).

What about the (probably more common) case that the inlined version is
smaller because of optimizations that are not possible in the general
case?

> The saving is estimated at (count-1) * (size-6), eg the estimate for a
> function call is 6 bytes as well and the estimate for the size something
> takes as inlined is the same as the uninline size.

Maybe the estimate is a little bit too rough. All savings add up to
1780743 bytes, which seems a bit too large to me (can't compare to the
total size of an allyesconfig kernel since that gives me a 'File size
limit exceeded' when linking).

What about the previous suggestion to remove inline from *all* static
inline functions in .c files?
I just tried that for the fun of it. It got rid of 8806 'inline'
annotations and produced the ~2 MB (uncompressed) patch at
http://www.physik3.uni-rostock.de/tim/kernel/2.6/deinline.patch.gz
The resulting kernel actually booted (am running it right now). However,
catching just these low-hanging fruits doesn't get me anywhere near
Arjan's numbers. For my non-representative personal config I get (on
i386 with -unit-at-a-time):

> size vmlinux*
text data bss dec hex filename
2197105 386568 316840 2900513 2c4221 vmlinux
2144453 392100 316840 2853393 2b8a11 vmlinux.deinline

I just started an allyesconfig build to get some real numbers.

Tim