This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: What to do with new-ra for GCC 4.0


On Tue, 2005-01-04 at 12:34 +0100, Steven Bosscher wrote:
> On Jan 04, 2005 11:54 AM, Jan Vroonhof <jvlists@ntlworld.com> wrote:
> 
> > > Bingo.
> > > Heck, i helped write it and i agree.
> > > new-ra has failed, long live a new new-ra
> > 
> > Is there a discussion somewhere of what went wrong so any "new new-ra"
> > can learn form them?
> 
> Of course such discussions have taken place, but many of them are
> probably not archived.  I've summarized my impression of them below.
> 
> > IIRC "new-ra" uses/used all the sexy modern ra
> > algorithms
> 
> That is part of the problem: it didn't choose one set of algorithms
> but just implemented them all.  Actually that's not so hard to fix,
> but someone would have to do it and it hasn't happened.
> 
> Some other problems I've heard mentioning:
[ ... ]
So here's a thought.

Instead of rewriting the register allocator, let's start with rewriting
reload, then global & local rather than the other way around.

In fact, I'm probably start from the end of reload and work backwards
within reload itself.  I wouldn't be terribly surprised if we could
formulate most of reload's actions as a subclass of register allocation
via graph coloring.

> 1) It tries *really* hard to do well for subregs, which is kinda
>    nice, but it causes an immense amount of cruft in the register   
>    allocator, throughout.  The proper fix would be to try and
>    avoid subregs as much as possible, and leave it to reload to
>    fix up that mess.
I would tend to disagree.  Yes, I'd like to avoid subregs, but I think
they are going to be unavoidable for a long long time.  And doing a 
good job on them is actually reasonably important.

> 
> 2) The version on mainline finds itself overruled by reload too
>    often.  The fix on the new-regalloc branch is pre-reload, which
>    is an excelent idea IMHO, except that pre-reload.c is just a
>    stripped version of reload{,1}.c, which is exactly what new-ra
>    was supposed to get rid of.  Too fight evil, you have to become
>    evil...
Which is why I suggested we start by working backwards from the
end of reload, eventually working all the way back to register
classing and regmove.  All the while working with the ultimate
goal of a graph coloring register allocator with integrated register
rematerialization.  

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]