From: Andi Kleen <ak@suse.de>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org, akpm@osdl.org, mingo@elte.hu
Subject: Re: [patch 2/7] enable unit-at-a-time optimisations for gcc4
Date: 07 Jan 2006 01:05:16 +0100 [thread overview]
Message-ID: <p73k6dcykar.fsf@verdi.suse.de> (raw)
In-Reply-To: <20060106184841.GA13917@mars.ravnborg.org>
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
next prev parent reply other threads:[~2006-01-07 0:05 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-06 10:37 [patch 1/7] Make __always_inline actually force always inlining Arjan van de Ven
2006-01-06 10:38 ` [patch 2/7] enable unit-at-a-time optimisations for gcc4 Arjan van de Ven
2006-01-06 17:18 ` Jeff Garzik
2006-01-06 18:48 ` Sam Ravnborg
2006-01-06 19:00 ` Arjan van de Ven
2006-01-06 19:02 ` Jeff Garzik
2006-01-06 23:56 ` Sam Ravnborg
2006-01-07 0:05 ` Andi Kleen [this message]
2006-01-07 0:20 ` Matt Mackall
2006-01-07 1:11 ` Andi Kleen
2006-01-07 8:47 ` Sam Ravnborg
2006-01-07 9:07 ` Andrew Morton
2006-01-07 10:03 ` Sam Ravnborg
2006-01-07 10:13 ` Andrew Morton
2006-01-07 12:00 ` Sam Ravnborg
2006-01-06 10:39 ` [patch 3/7] mark several functions __always_inline Arjan van de Ven
2006-01-06 10:41 ` [patch 4/7] Mark some key VFS functions as __always_inline Arjan van de Ven
2006-01-06 10:50 ` Al Viro
2006-01-06 10:42 ` [patch 5/7] uninline capable() Arjan van de Ven
2006-01-06 11:18 ` Michael Buesch
2006-01-06 11:22 ` Arjan van de Ven
2006-01-06 11:26 ` Michael Buesch
2006-01-08 5:51 ` [PATCH 1/4] move capable() to capability.h Randy.Dunlap
2006-01-08 7:45 ` Valdis.Kletnieks
2006-01-08 13:48 ` Randy.Dunlap
2006-01-08 18:02 ` Tim Schmielau
2006-01-09 1:55 ` Randy.Dunlap
2006-01-08 18:15 ` Tim Schmielau
2006-01-08 19:03 ` Andrew Morton
2006-01-08 17:19 ` [patch 5/7] uninline capable() Tim Schmielau
2006-01-07 0:28 ` Matt Mackall
2006-01-06 10:43 ` [patch 6/7] Unlinline a bunch of other functions Arjan van de Ven
2006-01-06 12:11 ` [PATCH] pktcdvd: Un-inline some functions Peter Osterlund
2006-01-06 17:29 ` [patch 6/7] Unlinline a bunch of other functions Jeff Garzik
2006-01-07 6:28 ` Andrew Morton
2006-01-06 10:45 ` [patch 7/7] Make "inline" no longer mandatory for gcc 4.x Arjan van de Ven
2006-01-06 17:31 ` Jeff Garzik
2006-01-06 19:35 ` Arjan van de Ven
2006-01-07 6:33 ` Andrew Morton
2006-01-07 8:34 ` Arjan van de Ven
2006-01-07 19:05 ` Kurt Wall
2006-01-07 19:10 ` Arjan van de Ven
2006-01-07 19:44 ` Arjan van de Ven
2006-01-07 22:13 ` Kurt Wall
2006-01-08 3:16 ` Kurt Wall
2006-01-08 3:56 ` Mitchell Blank Jr
2006-01-08 7:14 ` Kurt Wall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=p73k6dcykar.fsf@verdi.suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox