This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc300 benchmarks slower than gcc295.3?
- To: "Steven G. Johnson" <stevenj at alum dot mit dot edu>
- Subject: Re: gcc300 benchmarks slower than gcc295.3?
- From: tm <tm at kloo dot net>
- Date: Wed, 18 Jul 2001 02:39:55 -0700
- Cc: gcc at gcc dot gnu dot org, scox at redhat dot com
- References: <Pine.LNX.4.21.0107171847130.20101-100000@ab-initio.mit.edu>
"Steven G. Johnson" wrote:
>
> For a simple example of a code (for single-precision, so 8-byte
> alignment is not an issue) that gcc 3.0 does significantly worse on than
> 2.95.3, with an analysis of the assembly output, see also:
>
> http://gcc.gnu.org/ml/gcc-bugs/2001-06/msg01553.html
>
> We've seen regressions elsewhere as well, and I think that the
> optimization flaws in gcc 3.0 are real. Hopefully, this kind of
> performance bug will see a rapid improvement to at least 2.95.3 levels in
> upcoming gcc releases...
>
> Cordially,
> Steven G. Johnson
I think I understand what's happening.
In gcc 3.0, the 'addl" instruction is being forced to use register
operands. In this case, it causes two extra spills/restores to
be generated, which would be fine except as a side effect this
causes another two extra spills/restores to be generated.
On the x86, forcing the destination of a arithmetic instruction
is a huge win becuase it avoids the read/modify/write pipeline
interlock. However, forcing the source into a register is less
of a win, and as this case demonstrates, is probably a loss
because it increases register pressure.
I would investigate this problem further, but it's 2:39 am
and I need to retire to bed...
Toshi