aboutsummaryrefslogtreecommitdiff
path: root/gcc/config.gcc
diff options
context:
space:
mode:
authorRoger Sayle <roger@nextmovesoftware.com>2022-05-24 15:18:56 +0100
committerRoger Sayle <roger@nextmovesoftware.com>2022-05-24 15:18:56 +0100
commite8a25550dac458a2afd8d456540e94e060fa2384 (patch)
treedb87c6ca8900ef43e803cf1922166474602b6115 /gcc/config.gcc
parent793f847ba7dbe7638f1c27178868edbefd3a8108 (diff)
downloadgcc-e8a25550dac458a2afd8d456540e94e060fa2384.zip
gcc-e8a25550dac458a2afd8d456540e94e060fa2384.tar.gz
gcc-e8a25550dac458a2afd8d456540e94e060fa2384.tar.bz2
Optimize double word negation of zero extended values on x86.
It's not uncommon for GCC to convert between a (zero or one) Boolean value and a (zero or all ones) mask value, possibly of a wider type, using negation. Currently on x86_64, the following simple test case: __int128 foo(unsigned long x) { return -(__int128)x; } compiles with -O2 to: movq %rdi, %rax xorl %edx, %edx negq %rax adcq $0, %rdx negq %rdx ret with this patch, which adds an additional peephole2 to i386.md, we instead generate the improved: movq %rdi, %rax negq %rax sbbq %rdx, %rdx ret [and likewise for the (DImode) long long version using -m32.] A peephole2 is appropriate as the double word negation and the operation providing the xor are typically only split after combine. In fact, the new peephole2 sequence: ;; Convert: ;; xorl %edx, %edx ;; negl %eax ;; adcl $0, %edx ;; negl %edx ;; to: ;; negl %eax ;; sbbl %edx, %edx // *x86_mov<mode>cc_0_m1 is nearly identical to (and placed immediately after) the existing: ;; Convert: ;; mov %esi, %edx ;; negl %eax ;; adcl $0, %edx ;; negl %edx ;; to: ;; xorl %edx, %edx ;; negl %eax ;; sbbl %esi, %edx One potential objection/concern is that "sbb? %reg,%reg" may possibly be incorrectly perceived as a false register dependency on older hardware, much like "xor? %reg,%reg" may be perceived as a false dependency on really old hardware. This doesn't currently appear to be a concern for the i386 backend's *x86_move<mode>cc_0_m1 as shown by the following test code: int bar(unsigned int x, unsigned int y) { return x > y ? -1 : 0; } which currently generates a "naked" sbb: cmp esi, edi sbb eax, eax ret If anyone does potentially encounter a stall, it would easy to add a splitter or peephole2 controlled by a tuning flag to insert an additional xor to break the false dependency chain (when not optimizing for size), but I don't believe this is required on recent microarchitectures. 2022-05-24 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog * config/i386/i386.md (peephole2): Convert xor;neg;adc;neg, i.e. a double word negation of a zero extended operand, to neg;sbb. gcc/testsuite/ChangeLog * gcc.target/i386/neg-zext-1.c: New test case for -m32. * gcc.target/i386/neg-zext-2.c: New test case for -m64.
Diffstat (limited to 'gcc/config.gcc')
0 files changed, 0 insertions, 0 deletions