[4.9] PR 62146

Easwaran Raman eraman@google.com
Tue Sep 2 18:52:00 GMT 2014


It turns out that the REG_EQUAL note is removed on a hoisted
instruction (relevant code is in dead_or_predicable in ifcvt.c) if the
source of the move instruction is not a function invariant. In this
case, the source is a function invariant (constant) and so that
doesn't kick in. I don't understand why this exemption for function
invariant is there and the original thread in
https://gcc.gnu.org/ml/gcc/2005-05/msg01710.html doesn't explain
either. Should I just remove the REG_EQUAL notes of all hoisted
instructions or are there cases where it is safe to leave the note?

Thanks,
Easwaran



On Fri, Aug 29, 2014 at 1:06 PM, Jeff Law <law@redhat.com> wrote:
> On 08/25/14 16:42, Easwaran Raman wrote:
>>
>> This patch deletes REG_EQUAL note when a src register is replaced by a
>> constant in an assignment. This is to prevent spurious equivalences
>> between the constant and the expression in the REG_EQUAL note. In the
>> bug reported in PR 62146, an assignment in one branch (which is
>> actually dead) of an IF statement has a REG_EQUAL note equating a
>> register with an expression. Conditional copy propagation replaces the
>> register with 0. The instruction is hoisted above the branch
>> subsequently and then the value 0 is equated with the expression in
>> the REG_EQUAL. Is this ok for 4.9 branch if all tests pass?
>>
>> This patch looks applicable to trunk as well, but I don't have a test
>> case to reproduce the issue in trunk.
>
> Something doesn't feel right with this patch.  It seems to me the real
> problem is when when hoist the insn with the note.  If the equivalence
> implied by the note is no longer valid at the insn's new location, then the
> note needs to be removed.
>
> Now determining if the note is no longer valid at the new location may prove
> difficult ;-)  You'd probably have to know why the note was created, how it
> was changed, etc.  So I suspect the right thing to do is just remove
> REG_EQUAL notes on any insns we hoist in this manner.
>
> Jeff



More information about the Gcc-patches mailing list