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 43155 - [X68] r270109 can create dead stack adjustments after noreturn calls (previously PR27140)
Summary: [X68] r270109 can create dead stack adjustments after noreturn calls (previou...
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Backend: X86 (show other bugs)
Version: trunk
Hardware: PC Windows NT
: P enhancement
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-28 12:55 PDT by Reid Kleckner
Modified: 2019-08-30 14:02 PDT (History)
5 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Reid Kleckner 2019-08-28 12:55:17 PDT
Here is my gnarly C test case to make this happen on Linux:

__attribute__((noreturn)) void exit_manyarg(int, int, int, int, int, int, int, int, int, int);
struct ByVal {
  int vals[10];
};
struct ByVal getbyval();

void make_push_unprofitable(struct ByVal);
void bar();
extern int gv1, gv2, gv3, gv4, gv5, gv6, gv7, gv8, gv9, gv10;
int foo(int c) {
  if (c)
    exit_manyarg(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
  make_push_unprofitable(getbyval());
  make_push_unprofitable(getbyval());
  make_push_unprofitable(getbyval());
  return 0;
}

$ clang -S -O2 check.c --target=x86_64-linux -o - -fPIC
...
        callq   exit_manyarg@PLT
        subq    $32, %rsp

This only happens with a noreturn function has stack arguments, which is rare for Linux. However for Win64, the caller must always reserve 32 bytes of stack space. Currently this bug doesn't happen on Win64, but I plan to make it stop setting TrapUnreachable, which will make it happen for all noreturn calls, and then it will matter.
Comment 1 Hans Wennborg 2019-08-29 01:23:34 PDT
I thought r270109 was supposed to prevent this, not the other way around :-/
Comment 2 Reid Kleckner 2019-08-30 14:02:14 PDT
r370409 should fix these cases.

I think when you were working on r270109 we were measuring code size of i686-windows-msvc for chromium, which uses /Oy- to preserve frame pointers, so the stack frame was frequently not reserved, which avoided this case.