Re: [patch 2/7] enable unit-at-a-time optimisations for gcc4

[Andi Kleen <ak@suse.de>]

Sam Ravnborg <sam@ravnborg.org> writes:

First I must object to the thread/patch title.  x86-64 always used
unit-at-a-time when available. Other architectures used the compiler
default which is on in newer gccs. Only a popular legacy architecture
didn't. It should reflect that.

> On Fri, Jan 06, 2006 at 12:18:42PM -0500, Jeff Garzik wrote:
> > 
> > ACK, with a note:  gcc also supports limited program-at-a-time -- you 
> > pass multiple .c files on the same command line, and specify a single 
> > output on the command line.
> > 
> > It would be nice to update kbuild to do this for single directory 
> > modules....
> 
> How much will it gain?

You just get cross inlining between .c files. Nothing more. 
Since the kernel  doesn't use -O3 only functions marked inline would
be considered for this. And the fraction of functions in .c 
files that are marked inline, but not static is probably very small.

The feature also has some drawbacks - last time I checked it
was still quite green (as in bananas). First it causes gcc 
to eat a lot more memory because it has to hold completely directories
worth of source in memory. This might slow things down if setups
that didn't swap before start doing this now.

I suspect it'll also run slower with this because it has some algorithms
that scale with the size of the input source and some of the
directories in the kernel can be quite big (e.g. i'm not 
sure letting a optimizer lose on all of xfs at the same 
time is a good idea)

And gcc is really picky about type compatibility between source files
with program-at-a-time.  If any types of the same symbols are
incompatible even in minor ways you get an ICE. That's technically
illegal, but tends to happen often in practice (e.g. when people
use extern) It might end up being quite a lot of work to clean this up.

I wouldn't bother implementing this right now - it's probably not
worth it for the inlining. 

If gcc ever makes this feature usable and fixes the problems and
actually learns more optimizations using it that could be
reconsidered. 

-Andi
-
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/