Repository navigation
Test failure: JIT\Regression\JitBlue\GitHub_21990\GitHub_21990\GitHub_21990.cmd #70263
Description
Activity
- addedJitStressCLR JIT issues involving JIT internal stress modesCLR JIT issues involving JIT internal stress modesarea-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMICLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
on Jun 5, 2022 - ghost addeduntriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner
on Jun 5, 2022 See #65903 (comment)
This test creates a huge OSR method funclet frame. Recall on Arm64 OSR funclets need to pad by the size of the Tier0 frame, to keep PSPSym offsets the same between funclet and OSR method. Here the Tier0 frame is huge, and so forces the OSR funclet to likewise have a huge frame, and so unfortunately it also then needs a stack probe.
I was hoping to fix this by moving the Arm64 PSPSym above the register saves area which would make the offset in the OSR method small. But this seems less feasible now.
Thinking about this again I wonder if the OSR method can just reuse the Tier0 PSPSym slot. It shouldn't be possible for the OSR method to need a PSPSym if the Tier0 method didn't have one (at least until we enable inlining of methods with EH). So that slot in the Tier0 frame is just sitting there unused, and the OSR method could co-opt it.
That would make the OSR method caller-SP relative PSPSym offset very low, and so the OSR funclets could stop this crazy padding.
and so unfortunately it also then needs a stack probe.
This is in addition to the normal funclet stack probe that already exists to support a large outgoing arg area?
and so unfortunately it also then needs a stack probe.
This is in addition to the normal funclet stack probe that already exists to support a large outgoing arg area?
Not sure? I need to take a fresh look at this.
- removeduntriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner
on Jun 8, 2022 Current OSR funclet prolog is
;; Test_GitHub_21990:TestGenericContext(int):int IN0045: 00010C mov x9, #0x9ce0 IN0046: 000110 sub sp, sp, x9 IN0047: 000114 stp fp, lr, [sp] IN0048: 000118 stp x19, x20, [sp,#32] IN0049: 00011C mov x2, #0x9ce0 IN004a: 000120 add x3, fp, x2 IN004b: 000124 str x3, [sp,#24]
Could be I'm abusing the frame style here. and while the OSR method can have a type 1 (or whatever style) as the "probing" happens in the Tier0 frame and it is inheriting the T0 SP, but the funclet needs to do its own probing to skip over the ginormous padding it needs to ensure the PSP sym is at the right caller-SP relative offset.
I think reusing T0 PSP slot in the OSR method is the right long-term solution, but it means that the OSR method, OSR funclet and Tier0 method have to agree on the size of the save area (since the PSP sym sits below this), which means that T0 needs to reserve a maximal save area, which means we need to have the OSR method share this save area like we do on x64.
Doing all that now seems perhaps complicated, so I'll look into doing probing first.
- ghost addedin-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged
on Jun 17, 2022 OSR funclets are the only case where we might need probing of the initial SP adjustment, as you mentioned in a comment in
genFuncletProlog:// With OSR we may see large values for fiSpDelta1 // (we really need to probe the frame, sigh)- added a commit that references this issue
on Jun 22, 2022 - added a commit that references this issue
on Jun 23, 2022 - ghost removedin-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged
on Jun 23, 2022 - ghost locked as resolved and limited conversation to collaborators
on Jul 23, 2022
runtime-jit-experimental,
jit_osr_stress_randomhttps://dev.azure.com/dnceng/public/_build/results?buildId=1807282&view=ms.vss-test-web.build-test-results-tab