[Bug rtl-optimization/42511] [4.5 Regression] bootstrap error in stage3 on alpha-linux-gnu

["ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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