[llvm-bugs] [Bug 39074] New: [clang-cl] Decide what to do about /Gs (set stack probe size)

[via llvm-bugs]

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: unassignedclangbugs at nondot.org
          Reporter: hans at chromium.org
                CC: llvm-bugs at lists.llvm.org, nicolasweber at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180925/108b589c/attachment.html>