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.
