Re: RFC -- update_equiv_regs and friends

[John Wehle <john at feith dot com>]

>On Tue, Feb 27, 2001 at 11:58:41PM -0700, Jeffrey A Law wrote:
>>   C. Prune equivalences which refer to dying registers.  Will hinder
>>      local-alloc's rematerialization efforts somewhat.
>> 
>>   E. Prune the bogus equivalences after local-alloc is finished
>>      with them, possibly by hacking up the code in reload which
>>      searches for equivalences.
>
>I would do a very simple variant of C and E.  Namely, limit
>equivalence finding to non-register general_operand's.

How about:

  1) Update the REG_EQUIV documentation so it describes the
     pseudo register problem.

  2) Change update_equiv_regs so it doesn't promote a REG_EQUAL note
     to a REG_EQUIV if there's a register mentioned.

  3) Change update_equiv_regs so it performs the optimization in the
     case of (REG_EQUAL && ! rtx_varies_p) in addition to REG_EQUIV.

I'm willing to do the work if I know what the testcase is that fails.

BTW:  This may also allow an earlier issue involving
PIC_OFFSET_TABLE_REG_CALL_CLOBBERED to be cleaned up.  Simplify have
equiv_init_varies_p return true in this case.  Bernd's hack to rtx_varies_p
is no longer necesssary since the REG_EQUAL note will mention a register
and will not be promoted to a REG_EQUIV note.

> This new equivalence finding code has caused a number of problems,
> some of which have been hacked around.

Sigh ... guilty as charged.  Are there other outstanding issues I
should know about?  In general I'd like to think that the new code
has been a step forward.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------