Re: Simple benchmarks with gcc-3_0-branch

[Toshi Morita <tm2 at best dot com>]

> Toshi Morita <tm2@best.com> writes:
> 
> > > 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.
> 
> Both of these should be taken care of, for the most part, in the new
> register allocator.  It's not quite done yet (splitting live ranges is
> trivial to implement, it's choosing when/what/where to split that is hard).
> We can spill things for part of their lifetime, or split live ranges
> where it might be helpful.

The new register allocator may mitigate the symptom of registers thrashing
to the stack, but I doubt it solves the root problem of overaggressive
optimization by previous passes.

> 
> > 
> > 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.
> > 
> Briggs calls this rematerialization, and implements it in his register
> allocator. 
> I'll eventually get to it.

It seems to me there are frequently situations where optimization A
enables optimization B to occur which allows optimization C to occur.

If, however, you decide the resultant code spills too many pseudos
and optmization A was to blame, then you would possibly need to undo
optimizations C and B prior to undoing optimization A.

Currently, it sounds like you would only need a register rematerializer that can
rematerialize values across multiple basic blocks with multiple dominators
and also possibly undo loop-specific optimizations such as biv-to-giv conversion?

However, as more optimizations are added prior to register allocation,
the register rematerializer would ideally need to be modified
to handle those as well.

Therefore it seems more straightforward to provide a generic framework for
rerunning optimizations and suppressing problematic transformations on
subsequent runs.

> 
> > 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.
> 
> No, it doesn't (well, not for the reasons you explain). It needs a
> register allocator that is good at knowing  when to spill things, and
> what to spill, etc. 

My first comment also applies here.

Toshi