Re: RFC -- update_equiv_regs and friends

[Daniel Berlin <dberlin at redhat dot com>]

Jeffrey A Law <law@redhat.com> writes:

> 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.

I would do D, given that B will occur as part of the new-allocator,
and C would probably be more trouble than it's worth, given that
local-alloc completely goes away in it.  (IE IMHO, it takes more time
to do C than the D or E, and it's kind of a wasted effort).
 

> 
> Thoughts?
> 
> 
> jeff