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

Ingo Molnar
2005-12-28T21:23:37Z

* Linus Torvalds <torvalds@osdl.org> wrote:

> On Wed, 28 Dec 2005, Arjan van de Ven wrote:
> >
> > yup that's why the patch only does it for gcc4, in which the inlining
> > heuristics finally got rewritten to something that seems to resemble
> > sanity...
>
> Is that actually true of all gcc4 versions? I seem to remember gcc-4.0
> being a real stinker.

all my tests were with gcc 4.0.2.

> > > Also, the inlining patch apparently makes code larger in some cases,
> > > so it's not even a unconditional win.
> >
> > .... as long as you give the inlining algorithm enough information.
> > -fno-unit-at-a-time prevents gcc from having the information, and the
> > decisions it makes are then less optimal...
> >
> > (unit-at-a-time allows gcc to look at the entire .c file, eg things like
> > number of callers etc etc, disabling that tells gcc to do the .c file as
> > single pass top-to-bottom only)
>
> I'd still prefer to see numbers with -funit-at-a-time only. I think
> it's an independent knob, and I'd be much less worried about that,
> because we do know that unit-at-a-time has been enabled on x86-64 for
> a long time ("forever"). So that's less of a change, I feel.

the two patches are completely independent, and the only reason i did
them together was because i was looking at .text size in general and
these were the two things that made a difference. Also, the inlining was
a loss in one of the .config's, unless combined with the wider-scope
unit-at-a-time optimization.

(there's a third thing that i was also playing with, -ffunction-sections
and -fdata-sections, but those dont seem to be reliable on the binutils
side yet.)

here are the isolated unit-at-a-time numbers as well:

text data bss dec hex filename
3286166 869852 387260 4543278 45532e vmlinux-orig
3259928 833176 387748 4480852 445f54 vmlinux-units -0.8%
3194123 955168 387260 4536551 4538e7 vmlinux-inline -2.9%
3119495 884960 387748 4392203 43050b vmlinux-inline+units -5.3%

so both inlining and unit-at-a-time is a win independently [although
inlining alone does bloat .data], but applied together they bring an
additional 1.6% of .text savings. All builds done with:

gcc version 4.0.2 20051109 (Red Hat 4.0.2-6)

how about giving the inlining stuff some more exposure in -mm (if it's
fine with Andrew), to check for any regressions? I'd suggest the same
for the unit-at-a-time thing too, in any case.

Ingo