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

["Sam Lauber" <sam124 at operamail dot com>]

Why would a graph coloring register allocator be an 
optimization opposed to a graph black-and-white register 
allocator? Should the SUBREG problems be a regression in
new-ra, or a regression in the stricter SUBREG patches, or
both? Someone should `rm -rf' the files and make a new 
graph-coloring register allocator. Sad.

Samuel Lauber

>> Perhaps not so surprisingly, new-ra is completely broken on mainline
>> at the moment.  Literally not a single non-empty file will compile
>> with -fnew-ra.
>> First of all there is a bug in ra-build.c:live_in() which has been
>> there since the merge from the edge-vector-branch.  Then we hit an
>> ICE on sibcalls in ra.c:reg_alloc(), which also must have been there
>> since ages.  The patch below sort-of fixes these two issues.  But
>> then we hit SUBREG problems, probably due to rth's stricter subreg
>> patches.  At that point I gave up.
>> So, any nontrivial code will ICE with -fnew-ra.  I hate to bring up
>> painful issues, but I would like to propose we remove all of new-ra
>> for GCC 4.0 as it is complete and utterly broken anyway, and given
>> that it has been broken for months without anyone complaining, it's
>> not like anyone will miss it.
>> Thoughts? 
> That sucks?
> The structure of the new-ra files is really reasonably elegant; it would
> be sad if it couldn't be salvaged.
> Are there major structural defects in it, which would be remediated best by
> writing a graph-coloring register allocator from scratch, or is it just
> suffering from bitrot?
> How many people understand the code?  :-)  Would more workers help?
-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze