Re: RFA: patch for register migration

[Daniel Berlin <dberlin at dberlin dot org>]

On Apr 21, 2004, at 9:07 AM, Andrew MacLeod wrote:

> On Tue, 2004-04-20 at 22:27, Daniel Berlin wrote:
> > On Apr 20, 2004, at 9:26 PM, Richard Kenner wrote:
> >
> > >     Reload is effectively spill code generation for us.
> > >     This is changing a decision on *what to spill*, not *how to spill
> > > it*.
> > >     Thus, it belongs in the register allocator, not reload.
> > >
> > > Except that reload currently decides which hard registers to allocate
> > > as
> > > spill registers, so it's involved in that decision already.
> > Which of course, is just one more thing reload *shouldn't* be doing 
> > (in
> > the general case. It is impossible to avoid currently in some cases,
> > given the way our backend is structured)
> > However, my objection is that we don't want to be making global
> > allocation decisions, then undoing them later, when we could just do
> > them right the first time, and not undo them.   We also shouldn't be
> > making reload do more, we should be making it do less.
> >
> > I'll say no more on the issue, since it's likely i'll be overruled
> > anyway, and the right way to do register allocation is among one of 
> > the
> > easiest topics to generate arguments about.
> > I've said my piece.
>
> I'll also add my two cents :-)
>
> I personally like/prefer the model of global colouring allocator
> running, then a specialized local allocator doing the spill code.

Which i'd love, but it's not what we have :)
Reload isn't a good specialized allocator so much as a horrible 
horrible mess.
If we had a good global allocator, instead of our global/local pair, i 
wouldn't have nearly as much of a problem with vlad's code as i do now. 
 But i'd be surprised if if vlad's code right now doesn't just end up 
compensating for a lot of bad local or global decisions.

It's at this point in the discussion i usually throw up my arms because 
someone will bring up some weird platform, and my answer quickly moves 
towards "just describe every constraint and cost you have, and solve it 
as an ILP model, and be done with it".  Or possibly a PBQP model, if we 
could.  Here's hoping we have the computing power to do that in 5-10 
years.


> In order to do global allocation in a single iteration the local spill
> code allocator has to be able to spill a pseudo previously allocated to
> a hardware register at the local level. (just for a short duration, so
> its not undoing global decisions, just releaving the pressure at the
> worst points) I like to refer to this as spilling a hardware register
> :-)  These are the points in the function which would normally cause 
> the
> global allocator to iterate.

Right right.