[llvm-bugs] [Bug 31962] New: X86FrameLowering::emitSPUpdate generates inefficient code for epilogues with very large stacks.

[via llvm-bugs]

http://bugs.llvm.org/show_bug.cgi?id=31962

            Bug ID: 31962
           Summary: X86FrameLowering::emitSPUpdate generates inefficient
                    code for epilogues with very large stacks.
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: simon.dardis at imgtec.com
                CC: llvm-bugs at lists.llvm.org

The following code generates inefficient stack updates for the epilogue on X86:

    int main(void) {
        int x[600000000];
        return 0;
    }

When compiled for 'x86_64-apple-darwin15.2.0', generates the following:

        movabsq $2399999888, %rax       # imm = 0x8F0D1790
        subq    %rax, %rsp
        xorl    %eax, %eax
        movl    $0, -4(%rbp)
        addq    $2147483647, %rsp       # imm = 0x7FFFFFFF
        addq    $252516241, %rsp        # imm = 0xF0D1791
        popq    %rbp
        retq

Tracing the behaviour of emitEpilogue shows that MBBI ends up pointing at
POP64r when emitSPUpdate is called. emitSPUpdate in turn calls
findDeadCallerSavedReg which attempts to match MBBI against the X86 backend's
return instructions. Since MBBI is pointing to POP64r, no register is found, so
multiple addqs are generated to perform the stack pointer update.

I found this bug report on HN with the following code:

    #include <stdint.h>
    int main(void) {
        int x[SIZE_MAX / 32];
        return 0;
    }

Which on my machine caused clang to consume 8+ gigabytes of memory before I
terminated it. I reduced to it to the first example.

That code can be compiled with -momit-leaf-frame-pointer -fno-stack-protector
for 'x86_64-apple-darwin15.2.0' but without the pair of those options, llvm
appears to be trying to generate large amounts of addq instructions.

Thanks to bluetomcat for reporting the issue!

-- 
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/20170215/a636d3a5/attachment.html>