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

[Ingo Molnar]

this patchset (for the 2.6.16 tree) consists of two patches:

  gcc-no-forced-inlining.patch
  gcc-unit-at-a-time.patch

the purpose of these patches is to reduce the kernel's .text size, in 
particular if CONFIG_CC_OPTIMIZE_FOR_SIZE is specified. The effect of 
the patches on x86 is:

    text    data     bss     dec     hex filename
 3286166  869852  387260 4543278  45532e vmlinux-orig
 3194123  955168  387260 4536551  4538e7 vmlinux-inline
 3119495  884960  387748 4392203  43050b vmlinux-inline+units
  437271   77646   32192  547109   85925 vmlinux-tiny-orig
  452694   77646   32192  562532   89564 vmlinux-tiny-inline
  431891   77422   32128  541441   84301 vmlinux-tiny-inline+units

i.e. a 5.3% .text reduction (!) with a larger .config, and a 1.2% .text 
reduction with a smaller .config.

i've also done test-builds with CC_OPTIMIZE_FOR_SIZE disabled:

   text    data     bss     dec     hex filename
4080998  870384  387260 5338642  517612 vmlinux-speed-orig
4084421  872024  387260 5343705  5189d9 vmlinux-speed-inline
4010957  834048  387748 5232753  4fd871 vmlinux-speed-inline+units

so the more flexible inlining did not result in many changes [which is 
good, we want gcc to inline those in the optimized-for-speed case], but 
unit-at-a-time optimization resulted in smaller code - very likely 
meaning speed advantages as well.

unit-at-a-time still increases the kernel stack footprint somewhat (by 
about 5% in the CC_OPTIMIZE_FOR_SIZE case), but not by the insane degree 
gcc3 used to, which prompted the original -fno-unit-at-a-time addition.

so i think the combination of the two patches is a win both for small 
and for large systems. In fact the 5.3% .text reduction for embedded 
kernels is very significant.

the patches are against -git, and were test-built and test-booted on 
x86, using gcc 4.0.2.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/