Assertion failed 'codeGen->isFramePointerUsed() || varDsc->GetStackOffset() >= 0'

[BruceForstall]

I see several of these in the SPMI replay job (https://dev.azure.com/dnceng/public/_build?definitionId=1055&_a=summary):

ISSUE: <ASSERT> #48953 C:\gh\runtime6\src\coreclr\jit\lclvars.cpp (5360) - Assertion failed 'codeGen->isFramePointerUsed() || varDsc->GetStackOffset() >= 0' in '<>c:<EmitMatchCharacterClass>b__130_1(Span1,ValueTuple2):this' during 'Generate code' (IL size 88; hash 0x34b0649e; Tier1-OSR)

Specifically, for JitStressRegs=1/2/3/8, in the aspnet collection.

Note that this is a Tier1-OSR compilation.

If I attempt to repro just the one compilation:

C:\gh\runtime6\artifacts\tests\coreclr\windows.x64.Checked\Tests\Core_Root\superpmi.exe -c 48953 -jitoption JitStressRegs=1 -jitoption TieredCompilation=0 C:\gh\runtime6\artifacts\tests\coreclr\windows.x64.Checked\Tests\Core_Root\clrjit.dll c:\spmi\mch\b2d3c86f-87fd-4724-9e5d-4c44905eba91.windows.x64\aspnet.run.windows.x64.checked.mch

The failure doesn't repro.

If I run a set of compilations, -c 48900-48953, then it repros. That indicates that either SPMI replay or the JIT is storing data between SPMI replays, which is bad. Possibly environment settings or compilation flags?

One thing to note: superpmi_replay.py is forcing passing -jitoption TieredCompilation=0. This doesn't make sense, as it's overriding the SPMI collection, which will affect OSR playback (and probably lead to "MISSING" data). We should remove this. It was probably done because the replay job mostly invokes JitStressRegs, which wouldn't do anything in MinOpts compilations. But it seems likely forcing TieredCompilation=0 won't work for replays anyway.

In fact, removing -jitoption TieredCompilation=0, -c 48900-48953 succeeds. However, a full run still leads to this assert.

@AndyAyersMS
cc @dotnet/jit-contrib

Tagging subscribers to this area: @JulieLeeMSFT
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I see several of these in the SPMI replay job (https://dev.azure.com/dnceng/public/_build?definitionId=1055&_a=summary):

ISSUE: <ASSERT> #48953 C:\gh\runtime6\src\coreclr\jit\lclvars.cpp (5360) - Assertion failed 'codeGen->isFramePointerUsed() || varDsc->GetStackOffset() >= 0' in '<>c:<EmitMatchCharacterClass>b__130_1(Span1,ValueTuple2):this' during 'Generate code' (IL size 88; hash 0x34b0649e; Tier1-OSR)

Specifically, for JitStressRegs=1/2/3/8, in the aspnet collection.

Note that this is a Tier1-OSR compilation.

If I attempt to repro just the one compilation:

C:\gh\runtime6\artifacts\tests\coreclr\windows.x64.Checked\Tests\Core_Root\superpmi.exe -c 48953 -jitoption JitStressRegs=1 -jitoption TieredCompilation=0 C:\gh\runtime6\artifacts\tests\coreclr\windows.x64.Checked\Tests\Core_Root\clrjit.dll c:\spmi\mch\b2d3c86f-87fd-4724-9e5d-4c44905eba91.windows.x64\aspnet.run.windows.x64.checked.mch

The failure doesn't repro.

If I run a set of compilations, -c 48900-48953, then it repros. That indicates that either SPMI replay or the JIT is storing data between SPMI replays, which is bad. Possibly environment settings or compilation flags?

One thing to note: superpmi_replay.py is forcing passing -jitoption TieredCompilation=0. This doesn't make sense, as it's overriding the SPMI collection, which will affect OSR playback (and probably lead to "MISSING" data). We should remove this.

In fact, removing -jitoption TieredCompilation=0, -c 48900-48953 succeeds. However, a full run still leads to this assert.

@AndyAyersMS
cc @dotnet/jit-contrib

Author:	BruceForstall
Assignees:	AndyAyersMS
Labels:	area-CodeGen-coreclr
Milestone:	7.0.0

[BruceForstall]

Now that #67489 has merged, these are (almost) the only failures in the superpmi replay job.

Unfortunately, we have no way (currently) to disable individual failures, so these will continue to fail until this issue is resolved.

[AndyAyersMS]

I should be able to look into this tomorrow. But (as I noted over in #67489 I don't see why not setting TieredCompilation=0 should matter.

[AndyAyersMS]

In the failing case:

---OSR--- V00 (on tier0 frame) tier0 FP-rel offset 16 tier0 frame offset -8 new virt offset 8
---OSR--- V01 (on tier0 frame) tier0 FP-rel offset 24 tier0 frame offset -8 new virt offset 16
---OSR--- V02 (on tier0 frame) tier0 FP-rel offset 32 tier0 frame offset -8 new virt offset 24
---OSR--- V03 (on tier0 frame) tier0 FP-rel offset -60 tier0 frame offset -8 new virt offset -68
---OSR--- V04 (on tier0 frame) tier0 FP-rel offset -64 tier0 frame offset -8 new virt offset -72
---OSR--- V05 (on tier0 frame) tier0 FP-rel offset -68 tier0 frame offset -8 new virt offset -76
Assign V11 tmp5, size=4, stkOffs=-0x94
Assign V12 tmp6, size=4, stkOffs=-0x98
Assign V13 tmp7, size=4, stkOffs=-0x9c
Assign V20 tmp14, size=4, stkOffs=-0xa0
Assign V21 tmp15, size=8, stkOffs=-0xa8
Assign V22 tmp16, size=4, stkOffs=-0xac
---OSR--- V40 (promoted field of V62; on tier0 frame) tier0 FP-rel offset 32764 tier0 frame offset -8 field offset 0 new virt offset 32756
---OSR--- V41 (promoted field of V62; on tier0 frame) tier0 FP-rel offset 32764 tier0 frame offset -8 field offset 8 new virt offset 32764
Assign V63 cse0, size=4, stkOffs=-0xb0

vs the good case

---OSR--- V00 (on tier0 frame) tier0 FP-rel offset 16 tier0 frame offset -8 new virt offset 8
---OSR--- V01 (on tier0 frame) tier0 FP-rel offset 24 tier0 frame offset -8 new virt offset 16
---OSR--- V02 (on tier0 frame) tier0 FP-rel offset 32 tier0 frame offset -8 new virt offset 24
---OSR--- V03 (on tier0 frame) tier0 FP-rel offset -60 tier0 frame offset -8 new virt offset -68
---OSR--- V04 (on tier0 frame) tier0 FP-rel offset -64 tier0 frame offset -8 new virt offset -72
---OSR--- V05 (on tier0 frame) tier0 FP-rel offset -68 tier0 frame offset -8 new virt offset -76
Assign V11 tmp5, size=4, stkOffs=-0x94
Assign V12 tmp6, size=4, stkOffs=-0x98
Assign V13 tmp7, size=4, stkOffs=-0x9c
Assign V20 tmp14, size=4, stkOffs=-0xa0
Assign V21 tmp15, size=8, stkOffs=-0xa8
Assign V22 tmp16, size=4, stkOffs=-0xac
---OSR--- V40 (promoted field of V62; on tier0 frame) tier0 FP-rel offset 0 tier0 frame offset -8 field offset 0 new virt offset -8
---OSR--- V41 (promoted field of V62; on tier0 frame) tier0 FP-rel offset 0 tier0 frame offset -8 field offset 8 new virt offset 0
Assign V63 cse0, size=4, stkOffs=-0xb0

Here V62 is a promoted implicit byref

Changing the lvType for struct parameter V01 to TYP_BYREF.

lvaGrabTemp returning 62 (V62 tmp56) (a long lifetime temp) called for Promoted implicit byref.
Keeping promotion of implicit by-ref V02:  total: 3 non-call: 3 fields: 2
Changing the lvType for struct parameter V02 to TYP_BYREF

Not clear why we think it should be treated as an OSR local.