[llvm-bugs] [Bug 41398] New: Greedy spilling of registers before unlikely branch pessimizes likely code path

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41398

            Bug ID: 41398
           Summary: Greedy spilling of registers before unlikely branch
                    pessimizes likely code path
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Register Allocator
          Assignee: unassignedbugs at nondot.org
          Reporter: vgatherps at gmail.com
                CC: llvm-bugs at lists.llvm.org, quentin.colombet at gmail.com

Hi, when building the following code with both clang -Os and -O3 on x86_64:

int callme();

int test_function(int a, int b) {
    if (__builtin_expect(b < 10, 0)) {
        a += callme();
    }
    return a * b;
}

generates

test_function(int, int):
        pushq   %rbp
        pushq   %rbx
        pushq   %rax
        movl    %esi, %ebx
        movl    %edi, %ebp
        cmpl    $9, %esi
        jle     .LBB0_1
.LBB0_2:
        imull   %ebx, %ebp
        movl    %ebp, %eax
        addq    $8, %rsp
        popq    %rbx
        popq    %rbp
        retq
.LBB0_1:
        callq   callme()
        addl    %eax, %ebp
        jmp     .LBB0_2

instead of something like

test_function(int, int):

        cmpl    $9, %esi
        jle     .LBB0_1
.LBB0_2:
        imull   %edi, %esi
        movl    %esi, %eax
        retq
.LBB0_1:
        pushq   %edi
        pushq   %esi
        callq   callme()
        popq    %esi
        popq    %edi
        addl    %eax, %edi
        jmp     .LBB0_2

While it might be a valid decision to always save to stack if there's a likely
or normal call, this is undesirable behavior when the calling function is
marked as unlikely since branch probably won't get taken and the function
probably won't get called.

As a side note, when compiling with -Os, it would make more sense to just save
esi and edi instead of saving into non-scratch registers and pushing those old
values anyways, both from a code size and stack size perspective. This isn't
really the main point of the bug though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190405/6486ed5e/attachment.html>