This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.3 compile speed regression - AN ANSWER
- From: Andi Kleen <ak at suse dot de>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gcc at gcc dot gnu dot org, torvalds at transmeta dot com
- Date: 12 Feb 2003 17:57:50 +0100
- Subject: Re: GCC 3.3 compile speed regression - AN ANSWER
- References: <Pine.LNX.4.21.0302112309060.27558-100000@mail.kloo.net.suse.lists.egcs> <Pine.LNX.4.44.0302120827210.5230-100000@home.transmeta.com.suse.lists.egcs> <20030212164845.GA13175@nevyn.them.org.suse.lists.egcs>
Daniel Jacobowitz <drow@mvista.com> writes:
> Actually, we've got a lot of numbers that go the other way - someone
> earlier quoted a 10% improvement across SPEC, and it's not isolated to
> benchmarks. When people point the finger at particular code that gets
> worse, it seems to usually get fixed.
At least code size got much worse with 3.0 and 3.2 than 2.95. 3.2 -O2 compiled
code is generally much larger than 2.95 generated code.
The good news is that in 3.2 -Os actually works and brings great
improvements in many cases. Still it would be nice if the standard -O2
code was a bit leaner too.
I haven't compared 2.95 -O2 and 3.2 -Os, but I suspect 3.2 -Os is actually
slower.
In 3.2 -Os tends to be slightly slower in performance than -O2, but
it is usually left in the noise. In 2.95 interestingly -Os often
generated faster code than -O2.
I suspect the Linux kernel could be compiled with -Os without big
impact. If not for everything then at least for driver code. ACPI has
already switched to -Os in 2.5 (ACPI is only slow path code and saved
around ~70k with gcc 3.2)
NetBSD seems to use -Os for their kernel by default.
I personally often compile with -O1 for compiler speed reasons. It
is still too slow however.
-Andi