Re: RFA: patch for register migration

[Daniel Berlin <dberlin at dberlin dot org>]

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

> On Wed, 2004-04-21 at 09:24, Daniel Berlin wrote:
> >
>
> > > 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.
>
> Could be, but its sounds like a decent short term solution

Short term in our register allocator ends up being 5-10 years. :)

>  until someone
> gets the chutzpah to rewrite reload yet again, this time as a decent
> local allocator.

Bah, at this point, you'd probably be better off taking local alloc and 
turning it into that allocator.
Though i haven't looked closely enough at local-alloc in a while to say 
that for sure.
>  If he has implemented this in reload, it would vanish
> along with reload when/if it was rewritten.
>
> question, what kind of impact do these changes have using -fnew-ra?
I doubt it has much. new-ra knows to do this already (or rather, the 
one on the new-regalloc branch does as part of splitting around colors, 
but other code on the new-regalloc branch like pre-reload are in a 
shape where they generate such bad code that it makes actual 
benchmarking worthless).

> reload is still run is it not?
I dunno. I washed my hands of new-ra a while ago :P

> > 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.
> I wont :-), Im not concerned about weird platforms, they ought to be
> taken care of by the local spilling allocator as a normal part of
> buisiness via an interface for wacky-type architectures.

Whenever i sat down to design a good interface for doing this, someone 
came up with a wackier platform for gcc to support.
The interface quickly became "hand off all the info we've got to the 
port specific part, and you guys do whatever the hell you want with it. 
Give us back some info on what you did".