https://bugs.llvm.org/show_bug.cgi?id=39074
Bug ID: 39074
Summary: [clang-cl] Decide what to do about /Gs (set stack
probe size)
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: h...@chromium.org
CC: llvm-bugs@lists.llvm.org, nicolaswe...@gmx.de
Blocks: 13707
The MSDN docs about /Gs are a bit confusing.
They say "/Gs0 activates stack probes for every function call that requires
storage for local variables. This can have a negative impact on performance."
and "If the /Gs option is specified without a size argument, it is the same as
specifying /Gs0".
Yet they say /O1 and /O2 imply /Gs. Why would they do that if it has negative
impact on performance?
Also, I'm having trouble reproducing this locally. With MSVC from VS 2017:
a.cc:
int f(int x) { volatile int a[128] = {0}; return a[0];
cl /c /O1 a.cc && dumpbin /disasm a.obj
no stack probe
cl /c /O1 /Gs a.cc && dumpbin /disasm a.obj
no stack probe
cl /c /O1 /Gs0 a.cc && dumpbin /disasm a.obj
yes stack probe!
Okay, so maybe the doc is incorrect and /Gs doesn't mean /Gs0, but maybe it
means turn off stack probes? That would make sense with /O1 and /O2...
Adjusting a.cc to use more stack:
int f(int x) { volatile int a[4097] = {0}; return a[0]; }
cl /c /O1 a.cc && dumpbin /disasm a.obj
yes stack probe
cl /c /O1 /Gs a.cc && dumpbin /disasm a.obj
yes stack probe
cl /c /O1 /Gs100000 a.cc && dumpbin /disasm a.obj
no stack probe
cl /c /O1 /Gs100000 /Gs a.cc && dumpbin /disasm a.obj
yes stack probe
Well, since we still got a stack probe with /Gs, it doesn't seem to turn it
off.
I guess /Gs really just means use the default stack probe size (4096), and so
has no effect in practice.
If that's the case, we should make clang-cl behave accordingly; currently it
implements what the MSDN docs say.
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=13707
[Bug 13707] [meta] VCPP compatibility issues
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
