For x86/x64, call a stack probe helper for all frame sizes equal or over one page#44664
Conversation
…lper for larger frame sizes in codegenxarch.cpp
4000867 to
15b7556
Compare
|
@janvorli @BruceForstall PTAL - I ran dotnet/performance benchmarks on top of these changes. With help from @DrewScoggins we ran the same changes on our performance machines and, although there are some benchmarks that are slower with the change, looking at the historical data I can't reliably whether it's going make it's slower. Please let me know if you want me to share the data with you. |
BruceForstall
left a comment
There was a problem hiding this comment.
LGTM. btw, the title, "Always call a stack probe helper", is a too ambition. Instead, I would say "For x86/x64, call a stack probe helper for all frame sizes equal or over one page." The only difference here is we don't inline probe 2 and 3 page frames, which was an optimization someone added long, long ago (before my time) that has persisted.
|
btw, I think we need a detailed section the in the CLR ABI document, https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/botr/clr-abi.md, describing all the rules and restrictions and design constraints around stack probing on all the different platforms. (Or maybe it deserves its own document.) |
Yes, I do remember that I need to update the document (or create a new one as suggested). I am still in the process of deciding what should be done on Arm64. After that, I can go and describe all the implementations. |
janvorli
left a comment
There was a problem hiding this comment.
LGTM, as far as I can tell given my limited knowledge of JIT internals.
This is to avoid accessing stack below
rspin a prolog. This is how the probing is done in MSVC++ implementation for frames larger thanPAGE_SIZE.