What to do with new-ra for GCC 4.0

[Sam Lauber]

>>> I don't think anyone is disagreeing that gcc needs a new register allocator
>>> The suggestion is that the "new-ra" on mainline is sufficiently broken that
>>> it's better to rip it out and either start again or fix it on a branch than
>>> leave it to bitrot and get in the way on mainline.
If it is left to bitrot, it'll just get worse.

>> new-ra has failed, long live a new new-ra
> I'm agree.
> New-ra from mainline has failed (or just broken).

I completely disagree.
Ripping it out of mainline may not be the best option. There
was a lot of work in new-ra. Since the beginning of this
thread, I don't think anyone's ever bothered to look at what
gcc does with gdb, use the options that dump the RTL at
intermediate stages, or any of that. I think that everyone
is reluctant to debug new-ra. What is the point of getting
rid of perfectly good code, when one can debug it? I don't
think anyone would or should give up just because of a
giant swarm of bugs!
In my opinion, new-ra has gotten so bad because no one has
bothered to try it or debug it. -fnew-ra on nontrival code
in 3.4.3 works perfectly well! One of the points of the 
development model gcc and many other free software packages
use is everyone is encouraged to try it, break it, debug it,
and fix it.

Samuel Lauber
-- 
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze