* Linus Torvalds <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
