https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
Roger Sayle <roger at nextmovesoftware dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |roger at nextmovesoftware dot com --- Comment #15 from Roger Sayle <roger at nextmovesoftware dot com> --- Hi HJ (and Segher), The i386's *negsi_ccc_1 pattern fully models the flags setting behaviour of the x86's neg instruction. neg %eax, in addition to setting %eax to -%eax, will clear the carry flag if %eax is zero, and set it for all other values of %eax. Hence, this pattern is a useful mechanism for setting the carry flag to a known value from a scalar integer register. For example, it's used in the expansion of __builtin_add_with_carry (sp?). The *x86_movsicc_0_m1_neg instruction does the reverse. The sbc %eax,%eax instruction (subtract with carry) will place the value 0 in %eax if the carry flag is clear, and the value -1 in %eax if the carry flag is set (independent of whatever value was in %eax before the instruction). Understanding these patterns is perhaps a little easier with a little more context. For example, https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598058.html describes efforts to add support for x86's stc (set carry flag) and clc (clear carry flag) instructions. I've a similar patch for "cmc" (complement carry flag) but all of these are blocked by the simplify-rtx issue underlying PR 107172, that MODE_CC requires special care and/or backend specific support to interpret. Yes, a COMPARE rtx can be used to set various flags on x86, but many other operations also legitimately set and/or use MODE_CC, often in a parallel with the primary operation.