RFC -- update_equiv_regs and friends

[Daniel Berlin]

Joern Rennecke <amylaar@cambridge.redhat.com> writes:

> > I would do D, given that B will occur as part of the new-allocator,
> 
> Don't count your chickens until they are hatched.  First get that new
> allocator working for all targets, make it at least as good as the existing
> one, and then we can go about actually removing code that has been
> superceded.

I'm not, really. I'm just saying that since a *lot* of work will be
going into overhauling rematerialization for the new allocator, it
doesn't seem to make sense to spend a lot of time overhauling it in the the
current allocator, only to eventually make that code obsolete.

Even if the new allocator takes another year to become the default, I
still wouldn't see it  as worthwile to try to overhaul
rematerialization in the current one, only to throw it away in a year.

--Dan