Re: Simple benchmarks with gcc-3_0-branch

[Daniel Berlin <dberlin at redhat dot com>]

Toshi Morita <tm2@best.com> writes:


> 
> 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.

Okay, let's be clear.
Besides too much spilling, and extending register lifetimes, which are
the job solely of the register allocator, *what* exactly is the
problem you are seeing that will be solved? 

You only mentioned those two things, and put ",etc".
I'm not clear on what the "etc" is, so i can't agree or disagree on
whether the new register allocator will resolve those problems, or
could resolve them with work.

> 
> > 
> > > 
> > > 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.
Of course, there are optimization passes i'm working on that only help
enable other optimizations to be more effective.

> 
> 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.

I think you are attacking/viewing the problem from the wrong end.
It's not the optimizations fault there is too much spilling. It's the
register allocator's fault. 
> 
> 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?
It already does.

Look at http://compilers.iecc.com/comparch/article/95-03-009
Notice he raises the exact same issue you do, and the same response is
given "We let the register allocator handle it".

> 
> However, as more optimizations are added prior to register allocation,
> the register rematerializer would ideally need to be modified
> to handle those as well.
Not really. 
Since the register allocator is doing the spilling, it has the code
before it spills, and thus, only needs to be able to calculate what
the best thing to do is, and do it. It doesn't have to know how to
undo a given optimization, only how to recalculate a given values at a
certain point. And since it has the unspilled code, it knows how the
value is calculated.
> 
> Therefore it seems more straightforward to provide a generic framework for
> rerunning optimizations and suppressing problematic transformations on
> subsequent runs.
No, it doesn't. 
You are still looking at this from the wrong end, IMHO.
The register allocator is choosing what to spill, what not to spill,
etc. 
In fact, the only thing that knows whether something is going to be a
spill is the register allocator.
If you want it to know that it can and should, recalculate this value
rather than spill, you teach it how. 
It doesn't require undoing optimizations, because if you don't spill,
then there is no problem anyway, because you got everyting into
registers, and everyone is happy.
Your solution is overkill for the problem.
> > 
> > > 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.
As does mine.

> 
> Toshi