For x86/x64, call a stack probe helper for all frame sizes equal or over one page

[echesakov]

This is to avoid accessing stack below rsp in a prolog. This is how the probing is done in MSVC++ implementation for frames larger than PAGE_SIZE.

[echesakov]

@janvorli @BruceForstall PTAL - I ran dotnet/performance benchmarks on top of these changes.
There is no measurable performance impact - if a benchmark was Slower/Faster during the first run, it was showing the Same results for the second run.

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]

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.

[BruceForstall]

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.)

[echesakov]

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]

LGTM, as far as I can tell given my limited knowledge of JIT internals.