[Bug tree-optimization/112835] New: inverting the result of memcmp() produces inefficient code

[Bug tree-optimization/112835] New: inverting the result of memcmp() produces inefficient code

[gnu at kosak dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112835

            Bug ID: 112835
           Summary: inverting the result of memcmp() produces inefficient
                    code
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gnu at kosak dot com
  Target Milestone: ---

Created attachment 56778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56778&action=edit
the .ii file from --save-temps

Hello,

The assembly output of this program does a suboptimal thing in two different
places. It moves a constant (0 or 1) into %eax and then does a `testl` and
`sete` to invert that constant. This would be reasonable code for `!x` when x
is a runtime `int` value. However, when x is a constant, it would be simpler to
emit a single load instruction.

```
#include <cstring>

bool calc(const void *a, const void *b) {
    return !std::memcmp(a, b, 12);
}
```

Relevant assembly on x86_64, invoked with g++ -S -O3 test.cc

```
_Z4calcPKvS0_:
.LFB31:
        .cfi_startproc
        endbr64
        movq    (%rsi), %rax
        cmpq    %rax, (%rdi)
        je      .L5
.L2:
        movl    $1, %eax
        testl   %eax, %eax
        sete    %al
        ret
        .p2align 4,,10
        .p2align 3
.L5:
        movl    8(%rsi), %eax
        cmpl    %eax, 8(%rdi)
        jne     .L2
        xorl    %eax, %eax
        testl   %eax, %eax
        sete    %al
        ret
        .cfi_endproc

```

In the above, the code at label .L2 (movl/testl/sete) would be better off as
the single instruction "xorl %eax,%eax" and likewise the code at the latter
part of .L5 (xorl/testl/sete) would be better off as the single instruction
"movl $1, %eax". You can see the compiler doing this, though with inverted
logic, if you simply delete the ! in the source code.

Apologies if I've posted this to the wrong component.

Output from g++ -v:
```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 13.2.0-4ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-13-XYspKM/gcc-13-13.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-XYspKM/gcc-13-13.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Ubuntu 13.2.0-4ubuntu3) 
```

[Bug middle-end/112835] inverting the result of memcmp() produces inefficient code

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112835

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-12-03
             Target|                            |x86_64-linux-gnu
                   |                            |aarch64-linux-gnu
          Component|target                      |middle-end
           Keywords|                            |missed-optimization
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

aarch64 code generation is slightly better:
...
.L2:
        mov     w0, 1
        eor     w0, w0, 1
        ret
...
        mov     w0, 0
        eor     w0, w0, 1
        ret

But there is no reason for the mov followed by eor there, it should just be a
mov.

Note the gimple level is fine:
  _1 = __builtin_memcmp_eq (a_3(D), b_4(D), 12);
  _5 = _1 == 0;


Expansion does:
```
(jump_insn 14 13 33 4 (set (pc)
        (if_then_else (ne (reg:CC 66 cc)
                (const_int 0 [0]))
            (label_ref 19)
            (pc))) "/app/example.cpp":5:24 -1
     (int_list:REG_BR_PROB 708669604 (nil))
 -> 19)
(note 33 14 15 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 15 33 16 5 (set (reg:SI 92 [ _1 ])
        (const_int 0 [0])) "/app/example.cpp":5:24 -1
     (nil))
(jump_insn 16 15 17 5 (set (pc)
        (label_ref 21)) "/app/example.cpp":5:24 -1
     (nil)
 -> 21)
(barrier 17 16 18)
(barrier 18 17 19)
(code_label 19 18 34 6 2 (nil) [2 uses])
(note 34 19 20 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 20 34 21 6 (set (reg:SI 92 [ _1 ])
        (const_int 1 [0x1])) "/app/example.cpp":5:24 -1
     (nil))
(code_label 21 20 35 7 3 (nil) [1 uses])
(note 35 21 22 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
(insn 22 35 23 7 (set (reg:CC 66 cc)
        (compare:CC (reg:SI 92 [ _1 ])
            (const_int 0 [0]))) "/app/example.cpp":5:33 discrim 1 -1
     (nil))
(insn 23 22 24 7 (set (reg:SI 102)
        (eq:SI (reg:CC 66 cc)
            (const_int 0 [0]))) "/app/example.cpp":5:33 discrim 1 -1
     (nil))

```

Seems like we could do a better job at expansion here ...