On 06/06/2013 08:11 AM, Richard Earnshaw wrote: > I understand (and agree with) this bit... > >> +(define_peephole2 >> + [(set (reg:CC CC_REGNUM) >> + (compare:CC (match_operand:SI 0 "register_operand" "") >> + (match_operand:SI 1 "arm_rhs_operand" ""))) >> + (cond_exec (ne (reg:CC CC_REGNUM) (const_int 0)) >> + (set (match_operand:SI 2 "register_operand" "") (const_int 0))) >> + (cond_exec (eq (reg:CC CC_REGNUM) (const_int 0)) >> + (set (match_dup 2) (const_int 1))) >> + (match_scratch:SI 3 "r")] >> + "TARGET_32BIT && !peep2_reg_dead_p (3, operands[0])" >> + [(set (match_dup 3) (minus:SI (match_dup 0) (match_dup 1))) >> + (parallel >> + [(set (reg:CC CC_REGNUM) >> + (compare:CC (const_int 0) (match_dup 3))) >> + (set (match_dup 2) (minus:SI (const_int 0) (match_dup 3)))]) >> + (set (match_dup 2) >> + (plus:SI (plus:SI (match_dup 2) (match_dup 3)) >> + (geu:SI (reg:CC CC_REGNUM) (const_int 0))))]) >> + > > ... but what's this bit about?
The original intent was to revert back to the original peephole pattern (pre-PR 46975) when the CC reg is still live, but that doesn't properly maintain the CC state either (it just happened to pass in the test case I was looking at because I only cared about the Z flag, which is maintained the same). OK with the above bit left out? -- Meador Inge CodeSourcery / Mentor Embedded
