LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 27140 - [X86] Redundant adjacent stack adjustments after call frame optimization
Summary: [X86] Redundant adjacent stack adjustments after call frame optimization
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Backend: X86 (show other bugs)
Version: trunk
Hardware: PC Linux
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks: 26299
  Show dependency tree
 
Reported: 2016-03-30 15:33 PDT by Hans Wennborg
Modified: 2016-04-07 11:01 PDT (History)
3 users (show)

See Also:
Fixed By Commit(s):

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Hans Wennborg 2016-03-30 15:33:29 PDT 
For example

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

Compiled with Clang 3.8 for 32-bit x86 Linux at -Os:

g:
        subl    $12, %esp
        subl    $8, %esp
        pushl   $2
        pushl   $1
        calll   f
        addl    $16, %esp
        addl    $12, %esp
        retl


I'm working on a patch.
Comment 1 Quentin Colombet 2016-03-30 15:59:03 PDT 
Strange, this should already been handled by X86FrameLowering::mergeSPUpdates.
Comment 2 Hans Wennborg 2016-03-30 17:11:31 PDT 
(In reply to comment #1)
> Strange, this should already been handled by
> X86FrameLowering::mergeSPUpdates.

I think we need to call that some more :-) Sent out http://reviews.llvm.org/D18627
Comment 3 Hans Wennborg 2016-04-07 11:01:49 PDT 
r265623 fixes most of these. The impact was very small (~3KB on chrome_child.dll) but at least the code looks less silly.

There is still opportunities to clean up more %esp adjustment, for example if we're doing "add $4, %esp" but %esp is actually dead because we later do "mov %esp, %esi" or something, but that would be a different project, maybe part of PR27076.