[Bug rtl-optimization/111143] New: [missed optimization] unlikely code slows down diffutils x86-64 ASCII processing

["eggert at cs dot ucla.edu" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 111143
           Summary: [missed optimization] unlikely code slows down
                    diffutils x86-64 ASCII processing
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 55788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55788&action=edit
source code illustrating the performance problem

This bug report may be related to bug 110823 (also found for diffutils) but the
symptoms differ somewhat so I am reporting it separately. I observed it with
GCC 13.1.1 20230614 (Red Hat 13.1.1-4) on x86-64.

While tuning GNU diffutils I noticed that its loops to process mostly-ASCII
text were not compiled well by GCC on x86-64. For a stripped-down example of
the problem, compile the attached program with:

gcc -O2 -S code-mcel.c

The result is in the attached file code-mcel.s. Its loop kernel assuming ASCII
text (starting on line 44) looks like this:

        .L6:
                movsbq  (%rbx), %rax
                testb   %al, %al
                js      .L4
                addq    %rax, %r12
                movl    $1, %eax
        .L5:
                addq    %rax, %rbx
                cmpq    %r13, %rbx
                jb      .L6

The "movl $1, %eax" immediately followed by "addq %rax, %rbx" is poorly
scheduled; the resulting dependency makes the code run quite a bit slower than
it should. Replacing it with "addq $1, %rbx" and readjusting the surrounding
code accordingly, as is done in the attached file code-mcel-opt.s, causes the
benchmark to run 38% faster on my laptop's Intel i5-1335U.

It seems that code that GCC knows is unlikely (because of __builtin_expect) is
causing the kernel, which GCC knows is likely, to be poorly optimized.