[PATCH IRA] update_equiv_regs fails to set EQUIV reg-note for pseudo with more than one definition

[Alex Velenko]

On 09/02/15 23:32, Jeff Law wrote:
> On 02/03/15 20:03, Bin.Cheng wrote:
>> I looked into the test and can confirm the previous compilation is correct.
>> The cover letter of this patch said IRA mis-handled REQ_EQUIV before,
>> but in this case it is REG_EQUAL that is lost.  The full dump (without
>> this patch) after IRA is like:
> Right, but a REG_EQUIV is generated based on the incoming REG_EQUAL
> notes in the insn stream.  Basically update_equiv_regs will scan insn
> stream and some REG_EQUAL notes will be promoted to REG_EQUIV notes.

Hi Jeff,
Do I understand you correctly, that REG_EQUAL notes should not be
generated in IRA pass, because some of them may get promoted to
REG_EQUIV? Or is there any other reason register r110 should not get
REG_EQUAL note? Previously, register r110 was getting REG_EQUAL, not
REG_EQUIV note.
Kind regards,
Alex

>
> The REG_EQUIV is a function-wide equivalence, meaning that one could
> substitute the REG_EQUIV note for in any uses of the destination
> register and still have a valid representation of the program.
>
> REG_EQUAL's validity is limited to the point after the insn in which it
> appears and before the next insn.
>
>>
>> Before r216169 (with REG_EQUAL in insn9), jumps from basic block 6/7/8
>> -> 9 can be merged because r110 equals to -1 afterwards.  But with the
>> patch, the equal information of r110==-1 in basic block 8 is lost.  As
>> a result, jump from 8->9 can't be merged and two additional
>> instructions are generated.
>   >
>> I suppose the REG_EQUAL note is correct in insn9?  According to
>> GCCint, it only means r110 set by insn9 will be equal to the value at
>> run time at the end of this insn but not necessarily elsewhere in the
>> function.
> If you previously got a REG_EQUIV note on any of those insns it was
> wrong and this is the precise kind of situation that the change was
> trying to fix.
>
> R110 can have the value -1 (BB6, BB7, BB8) or 0 (BB5).  Thus there is no
> single value across the entire function that one can validly use for r110.
>
> I think you could mark this as a missed optimization, but not a
> regresssion since the desired output was relying on a bug in the compiler.
>
> If I were to start looking at this, my first thought would be to look at
> why we have multiple sets of r110, particularly if there are lifetimes
> that are disjoint.
>
>
>>
>> I also found another problem (or mis-leading?) with the document:
>> "Thus, compiler passes prior to register allocation need only check
>> for REG_EQUAL notes and passes subsequent to register allocation need
>> only check for REG_EQUIV notes".  This seems not true now as in this
>> example, passes after register allocation do take advantage of
>> REG_EQUAL in optimization and we can't achieve that by using
>> REG_EQUIV.
> I think that's a long standing (and incorrect) generalization.  IIRC we
> can get a REG_EQUIV note earlier for certain argument setup situations.
>    And I think it's been the case for a long time that a pass after
> reload could try to exploit REG_EQUAL notes.
>
> jeff
>