Re: Project RABLET

[Andrew MacLeod <amacleod at redhat dot com>]

On Fri, 2006-06-23 at 23:08 -0400, Daniel Berlin wrote:
> Ian Lance Taylor wrote:

> > 
> > Here I think you are waving your hands a little too hard.  RTL level
> > CSE is significant for handling common expressions exposed by address
> > calculations and by DImode (and larger) computations.  On some
> > processors giving up CSE on address calculations would be very
> > painful.  There needs to be a plan to handle that.
> 
> I agree with Ian completely.
> Also, after having stared and worked on df in the backend with Kenny and
> watched the amount of work that has had to be done, i think you may be
> underestimating the complexity of what is really going on in the backend
> right now.
> 
> Not that i wouldn't love to see our backend become simpler and have a
> bunch of relatively non-complex df based passes, because I would, but i
> *also* don't think RABLET is going to enable that (or the removal of
> CSE/GCSE) through smarter expand.  It's possible you'd remove GCSE, but
> only because the last time i remember someone looking (stevenb, i
> think), it wasn't doing all *that* much.
> 
> Again, like Ian, I'd argue you'd need to do real instruction selection
> before register allocation before that can happen.  Luckily, these days,
> BURG based instruction selection has become production usable, so that
> task isn't as horrid as it used to be.

It occurs to me I think there is a misunderstanding here. Perhaps I
didn't communicate this well enough, or perhaps I got a little carried
away trying to make RABLET look like RABLE.

Im not actually proposing that RABLET will enable the backend to
suddenly become simple... The initial impact of RABLET is to simply
remove some of the onus of dealing with excessive register pressure from
the register allocator.

RABLET will really do nothing when register pressure is not high, things
would be pretty much exactly as they are today.

When register pressure is high, many of the things the RTL optimizations
I mentioned do really become irrelevant (I think), since they increase
register pressure more, and cause more spilling. This generally offsets
whatever good they do. I was trying to claim that some level of this
work can be done in expand and in *this* circumstance, thats all that
needs to be done. Making the resulting model look somewhat like RABLE,
and simplifying the view of the RTL optimizations. 

Its possible that some of this work can simplify the RTL optimizations
in other cases, perhaps not. If we can simplify anything, that great.
I'd love to see it, and I hope some of it is possible. I do see
possibilities that will hopefully pan out.

Ultimately, RABLET simply tries to present the backend with code that
looks more like low register pressure code which the current backend is
pretty good at handling. Anything else we can get from it is a bonus.

For the work involved in RABLET vs. the work involved in a new allocator
like RABLE, I think RABLET is well worth doing. (months vs. years). I
think RABLET will show a significant benefit. (famous last words, ho
ho :-)

Andrew