https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89506
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Where we create larger code, it is:
(insn 7 6 8 2 (set (reg:SI 116)
(const_int -1 [0xffffffffffffffff])) "builtin-arith-overflow-1.c":11:1
181 {*arm_movsi_insn}
(nil))
(insn 8 7 9 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg/v:SI 114 [ x ])
(reg:SI 116)))
(set (reg:SI 115)
(minus:SI (reg/v:SI 114 [ x ])
(reg:SI 116)))
]) "builtin-arith-overflow-1.c":11:1 28 {subsi3_compare1}
(expr_list:REG_DEAD (reg:SI 116)
(expr_list:REG_DEAD (reg/v:SI 114 [ x ])
(nil))))
(jump_insn 9 8 12 2 (set (pc)
(if_then_else (ltu (reg:CC 100 cc)
(const_int 0 [0]))
(label_ref 12)
(pc))) "builtin-arith-overflow-1.c":11:1 203 {arm_cond_branch}
(expr_list:REG_DEAD (reg:CC 100 cc)
(int_list:REG_BR_PROB 536868 (nil)))
where cprop previously managed to turn that subsi3_compare1 into cmpsi2_addneg,
but now it doesn't. The question is, is
mvn r3, #0
subs r0, r0, r3
setting all the Z, N, C and V flags to the same values as
adds r0, r0, #1
for all the possible values of r0 or not?
And, should I split the
(*subsi3_carryin_compare_const): Similarly, just instead of -UINTVAL.
part of the patch to a separate, non-controversial, patch, to unbreak PR89434
fallout?
