------- Comment #22 from ubizjak at gmail dot com 2010-01-07 08:02 -------
(In reply to comment #21)
> > Because at the point of propagation, propagated constant _is_ equal to
> > whatever REG_EQUAL says. Removing this note at the point of propagation
> > would IMO disable much more optimization opportunities.
>
> What kind of opportunities exactly? The insn is more precise that the note.
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.
>
> > BTW: This fixup happens in very rare occasions. Although the loop looks
> > scary,
> > it usually processes very small BBs (I didn't found the case where more than
> > one assignment was moved at the top of the test BB.
>
> Yes, but removing REG_EQUAL notes pointing to constants seems a bad idea.
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.
--
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
