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