Simple benchmarks with gcc-3_0-branch

[Toshi Morita]

> I've put up a small benchmark page at
> 
> http://www.math.purdue.edu/~lucier/bench.html
> 
> comparing compile times and run times for programs that have been
> compiled from Scheme->C and then compiled with gcc-3_0-branch from a
> few days ago.  It's somewhat depressing to see how little going from
> -O1 to higher optimization levels buys you and how relatively often it
> hurts you.
> 
> Brad Lucier
> 
> PS:  The recently reported PR optimization/2001 (see the benchmark line
> for pi on the page given above) is a regression from 2.95.2, since the
> compile time in 2.95.2 was 3.32 seconds, and is 195.64 seconds in
> gcc-3_0-branch.

I don't know anything about the Alpha, so this is speculating quite
a bit, but in the past four years, I've looked through a few hundred
megabytes of GCC-generated SH2/SH4 assembly, and your problem sounds
very familiar.

I saw the same types of results on the Hitachi SH, and basically 
concluded it was due to overaggressive optimization passes creating
new pseudos and/or extending register lifetimes unnecessarily, and
causing pseudos to thrash to the stack.

I'm guesing you have the same problem because disabling GCSE improves
code efficiency. I have often seen the current implementation of GCSE
pessimize code because it doesn't consider register pressure when
optmiziming, and often it would be much faster to recalculate a trivial
subexpression than to create a new pseudo which thrashes to the stack.

IMHO GCC desperately needs the ability to estimate register pressure
and a framework for "throttling back" the aggressiveness of optimizations
which generate new pseudos and/or extend the lifeetimes of existing pseudos
in regions of high register pressure.

IIRC the Greenhills compiler does something similar to this.
They perform optimization once, and if the register pressure is high enough
they start from scratch and rerun the optimizer again with some optimizations
throttled and/or disabled.

Toshi