https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107404
--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> This is due to the peephole2 added in r12-2640-gf7bf03cf69cc:
>
> ;; Eliminate a reg-reg mov by inverting the condition of a cmov (#2).
> ;; mov r2,r3; mov r0,r1; dec r0; cmov r0,r2 -> dec r1; mov r0,r3; cmov r0, r1
The "dec" above in fact matches many other instructions, including:
(insn 485 960 737 19 (parallel [
(set (reg:CCC 17 flags)
(compare:CCC (plus:DI (reg:DI 43 r15 [orig:157 _138 ] [157])
(reg:DI 3 bx [orig:99 _23 ] [99]))
(reg:DI 3 bx [orig:99 _23 ] [99])))
(set (reg:DI 43 r15 [orig:157 _138 ] [157])
(plus:DI (reg:DI 43 r15 [orig:157 _138 ] [157])
(reg:DI 3 bx [orig:99 _23 ] [99])))
]) "pr107404.cpp":28:46 413 {*adddi3_cc_overflow_2}
(nil))
So, the processed sequence is:
bx <- [mem]
r15 <- r8
r15 <- r15 + bx
r15 <- (r15, bx)
and the sequence is converted to:
r8 <- r8 + bx
r15 <- [mem]
r15 <- (r8, r15)
However, the bx register in the first insn is uninitialized.
We can still allow unrelated registers in the "dec" instruction, under the
condition this register is not the one in the removed assignment. So, the
answer to:
> The conditions make sure that the 2<-3 and 0<-1 moves are independent,
> but they don't check what effect the 2<-3 move has on the third
> instruction. I don't know if the intention was to exclude cases
> where operands 5 and 6 reference operand 2, or whether the intention
> was to cope with those cases where possible.
is that we want to exclude cases where operand 6 references operand 2 (please
note that operand 5 is a duplicate of operand 6).
