[llvm-bugs] [Bug 27165] New: [X86] Consider not restoring the stack between calls

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Mar 31 09:41:33 PDT 2016


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

            Bug ID: 27165
           Summary: [X86] Consider not restoring the stack between calls
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: hans at chromium.org
                CC: llvm-bugs at lists.llvm.org
            Blocks: 26299
    Classification: Unclassified

Consider:

  void f(int);
  void g() {
    f(1);
    f(2);
  }

Compiled with -target i686-pc-win32 -Os, Clang generates:

00000000 <_g>:
   0:   6a 01                   push   $0x1
   2:   e8 00 00 00 00          call   7 <_g+0x7>
   7:   83 c4 04                add    $0x4,%esp
   a:   6a 02                   push   $0x2
   c:   e8 00 00 00 00          call   11 <_g+0x11>
  11:   83 c4 04                add    $0x4,%esp
  14:   c3                      ret


Since there is no need to align the stack, we could consider not restoring the
stack pointer between the two calls:

MSVC with /Ox:

  00000000: 6A 01              push        1
  00000002: E8 00 00 00 00     call        _f
  00000007: 6A 02              push        2
  00000009: E8 00 00 00 00     call        _f
  0000000E: 83 C4 08           add         esp,8
  00000011: C3                 ret 
                                                          

This saves code size at the expense of stack size.

If we used pops to restore the stack here (see PR26333) that might be cheaper
than a consolidated "addl $8, %esp" 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/20160331/92867872/attachment-0001.html>


More information about the llvm-bugs mailing list