------- Comment #23 from ebotcazou at gcc dot gnu dot org 2010-01-07 08:22
-------
> I'm thinking about the same situation with cse2, where constant assignment
> (with its REG_EQUAL note) would match another assignment with the same
> REG_EQUAL note. cse2 can equal this other assignment (through matching
> REG_EQUAL notes) to the constant - actually the same thing that happens in our
> problematic case. Since this transformation would happen in the same BB, it
> would be perfectly valid - and disabled by removing REG_EQUAL note on
> constant.
This mechanism very likely results in a bug if the 2 insns are not originally
in the same BB, like in the case at hand. So, assuming they are originally in
the same BB and carry the same REG_EQUAL note, the constant will be propagated
in both insns.
> Sure, but after the assigment was moved, REG_EQUAL points to invalid
> assignment, see this part from the dumps:
>
> 39 r78:DI=zero_extend(r154:QI)
> REG_DEAD: r154:QI
> REG_EQUAL: zero_extend([r152:DI])
> 583 r82:DI=0x0 << here
> REG_EQUAL: zero_extend([r152:DI])
> 40 pc={(r78:DI==0x0)?L230:pc}
> REG_BR_PROB: 0x1388
>
> The proposed change removes REG_EQUAL note only on moved insn, (insn 538) in
> our case.
That's too aggressive in the general case, no need to remove a REG_EQUAL note
pointing to a constant if the SRC is also function_invariant_p. An acceptable
compromise could be to remove the note only if its content is also not itself
function_invariant_p.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42511
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
