GCC trunk SPEC2000 performance

[Jan Hubicka]

> 	To avoid the argument that GCC 3.2 performance regressions were
> reported too late in the release cycle, does anyone know why the graphs on
> Andreas Jaeger's SPEC CPU2000 performance tracking page show:
> 
> 1) 181.mcf, 254.gap, 172.mgrid, performance has fallen precipitously.  The
> trunk produces worse code than GCC 2.95, 3.0, and 3.1.

I didn't had time to investigate these yet, but it is my TODO.
> 
> 2) "peak" (-O3 -funroll-all-loops -fprefetch=loop-arrays) produces slower
> code than base (-O2) for many tests.

The peak performance is due to -momit-frame-pointer.  This allows
register generation to do better job so it should be win, but it also
makes stack references longer resulting in slightly larger code.  The
slowdown, however looks much more serious that one caused by slight code
size increase and does not seem to happen for PentiumPro chips at all,
so it may be some weird hardware issue I am now aware of.  For K6 this
were problem with predecode state, that failed to predecode instruction
with long memory addressing whose opcode+modRM byte straddle decoder
window.  I have not information whetehr it is the case of Athlon and
hand checking shows even more sick results - I am able to move
perofmrance 20% back and fourth by adding nops into the code, but I
am not at all able to predict in what direction the change will happen.

Honza
> 
> David