This is the mail archive of the
mailing list for the GCC project.
RE: [PATCH IRA] update_equiv_regs fails to set EQUIV reg-note for pseudo with more than one definition
- From: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>
- To: Jeff Law <law at redhat dot com>, Bin.Cheng <amker dot cheng at gmail dot com>
- Cc: Alex Velenko <Alex dot Velenko at arm dot com>, Felix Yang <fei dot yang0953 at gmail dot com>, "Yangfei (Felix)" <felix dot yang at huawei dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, "vmakarov at redhat dot com" <vmakarov at redhat dot com>
- Date: Tue, 10 Feb 2015 10:51:25 +0000
- Subject: RE: [PATCH IRA] update_equiv_regs fails to set EQUIV reg-note for pseudo with more than one definition
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 126.96.36.199) smtp dot mailfrom=ajit dot kumar dot agarwal at xilinx dot com;
- References: <CAFc0fxz3Fdr9rgLscjTzZm0PoBn53y028tQU4=U0BXQ0kY6+KA at mail dot gmail dot com> <54206D2C dot 708 at redhat dot com> <DA41BE1DDCA941489001C7FBD7A8820E55542982 at szxema507-mbx dot china dot huawei dot com> <CAFc0fxzT7hTBONNt+_2EmQwW8jTmadPs6oWnDMRRD85=yUqzNg at mail dot gmail dot com> <CAFc0fxyu257uDv4twJiFUGd-g60NZLGyDNyQthDHwtwvPaXRpQ at mail dot gmail dot com> <5421B28F dot 1030006 at redhat dot com> <CAFc0fxx-3MA+MaeWK8eXktOP8+s3NPQMCUNvytmwJJ8FXXWQwA at mail dot gmail dot com> <5424659C dot 5040702 at redhat dot com> <CAFc0fxyBTaQOah3OBZUgs2UzQmn3RQzN4+Fm2Jou3V3=OYS4pw at mail dot gmail dot com> <5425D4A4 dot 20109 at redhat dot com> <CAFc0fxwiqbg5GHzXJczWCP1s7OWs-BKPfuwi1NiA9CwiYPUw5w at mail dot gmail dot com> <5429D2C5 dot 2090203 at redhat dot com> <CAFc0fxwGee-oj+H2C+NcJ_HZJfGH8zY2ZLuBpwCo0jD1koe6ww at mail dot gmail dot com> <54CF9ED6 dot 4080808 at arm dot com> <54D077B9 dot 1040906 at redhat dot com> <CAHFci2_h6=b7C9v6vBcpvPXmL3Uycg8B-4B8q33fABgS-kVj7g at mail dot gmail dot com> <54D0F73E dot 4090207 at redhat dot com> <CAHFci2__xyaXuj1nZorCqzqBtWgAzGCdknNjAT_rG5oPs3eZtQ at mail dot gmail dot com> <54D94399 dot 7010202 at redhat dot com>
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Jeff Law
Sent: Tuesday, February 10, 2015 5:03 AM
Cc: Alex Velenko; Felix Yang; Yangfei (Felix); Marcus Shawcroft; GCC Patches; firstname.lastname@example.org
Subject: Re: [PATCH IRA] update_equiv_regs fails to set EQUIV reg-note for pseudo with more than one definition
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
>>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.
Does the value of R110 should not change across all the callee path from the given caller functions. If the value is aliased, then how the call side affects should make
sure the value remains same across all the callee chain path from the given caller function. I am curious to know how the value remain constant throughout the function
is identified in case of aliasing and the interprocedural case.
>>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
>>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.
Thanks & Regards