RFC -- update_equiv_regs and friends

[Jeffrey A Law <law at redhat dot com>]

update_equiv_regs tries to find alternate forms of values in pseudos;
we do this to rematerialize values in cases where the pseudo does not
get a hard register (both in local register allocation and in reload).


That's all fine and good, except that it can create equivalences in
which the alternate form relies on other pseudos which might not be
live at the point where we want to rematerialize the original pseudo
that did not get a hard register.

Consider an insn like this:

(set (pseudo) (mem (lo_sum (tempreg) (symbol_ref))))

tempreg is likely going to die in that insn.

We may attach a REG_EQUIV note to that insn indicating that 
pseudo is equivalent to (mem (lo_sum (tempreg) (symbol_ref)).

reload sees the REG_EQUIV note and notes the equivalence.  It may then
substitute in the equivalent form for pseudo if pseudo doesn't get a
hard register.

That creates problems because reload doesn't extend the lifetime of
tempreg, nor does it re-initialize it before using it.

Possible solutions:

  A. Twiddle the PA backend so that update_equiv_regs doesn't see the
     equivalence.  This seems like papering over the bug to me.

  B. Overhaul rematerialization (deparately needed).  Unfortunately,
     I don't have time to do this.

  C. Prune equivalences which refer to dying registers.  Will hinder
     local-alloc's rematerialization efforts somewhat.

  D. Remove the code which is finding these equivalences (it's
     relatively recent code (came in on Sept 12, 2000).

  E. Prune the bogus equivalences after local-alloc is finished
     with them, possibly by hacking up the code in reload which
     searches for equivalences.

  F. Don't consider the first argument of a LO_SUM as special in
     rtx_varies_p.
 
My time is very limited, so I can't take on any large scale development
work to solve this problem.  Thus, I'm thinking seriously about A, C, D,
E & f.

Thoughts?


jeff