[AndyAyersMS]

Only specialize GDV guards that match the allocation's type during CEA cloning. Previously, a cloned boxed List enumerator could take an array-enumerator fast path.

Add a regression with opposing factory and iteration profiles and multiple GDV type checks.

Validation: Checked JIT build passed; the regression fails before the fix and passes afterward. Six neighboring test wrappers passed. The original NativeAOT repro improves from 2/5 to 5/5 correct results.

SPMI: 2,081,803 cached contexts, no assembly diffs or failing compiles; one context lacks data in both JITs. The 3,328-context NativeAOT repro collection changes only Dfa.DfaBuilder.Closure: 1,032 -> 1,130 bytes (+98 bytes, +9.50%). Stack allocation is retained.

Resolves #137063

Note

This PR description was generated by GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 5 pipeline(s).
10 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[AndyAyersMS]

Note this bug is currently NAOT specific, it only happens when we allow multiple GDV checks (NAOT enables 3 by default) and have a polymorphic profile. If we have this setup then we need to ensure that in the CEA clone we specialize the right checks (since there is more than one to choose from at each site).

Also note we are not anti-specializing the known to be wrong checks, which means the cloned code is slightly inefficient coming out of CEA, but these get cleaned up later on by RBO/AP.

If we just have a single GDV check and a polymorphic profile (which is what we normally see during jitting) then a diverging GDV will cause CEA to fail.

We apparently don't enable multi-guess GDV in PGO stress modes. Seems like we should.

[AndyAyersMS]

@jakobbotsch PTAL
fyi @dotnet/jit-contrib

Will probably want to backport this.

[Copilot]

🟢 Approval recommended

No active review issues are reported for the change restricting guard specialization to matching allocation types.

No open issues 🎉

What changed in this PR

This PR fixes incorrect guarded devirtualization during conditional escape analysis (CEA) cloning in the JIT by requiring guards to match the allocation’s type.

Changes:

• Restricts guard specialization to matching allocation types.
• Adds a regression with opposing factory-call and iteration profiles.
• Configures the regression for tiered compilation, dynamic profile-guided optimization, and multiple type checks.

File	Description
src/​tests/​JIT/​opt/​ObjectStackAllocation/​Runtime_137063.csproj	Configures isolated execution and optimization settings for the regression.
src/​tests/​JIT/​opt/​ObjectStackAllocation/​Runtime_137063.cs	Tests enumeration counts with conflicting type profiles.
src/​coreclr/​jit/​objectalloc.cpp	Checks guard type equality before specializing during cloning.

_{Review effort: Balanced}

[JulieLeeMSFT]

LGTM. The fix adds a type-match check so CEA uses the guard for the correct type when a call site has multiple GDV checks.

[JulieLeeMSFT]

Will probably want to backport this.

The author said that backport would work for them. We can skip backports.

[AndyAyersMS]

Will probably want to backport this.

The author said that backport would work for them. We can skip backports.

Did you mean to write "will not"? I think we should consider fixing this...

[AndyAyersMS]

Formatter failure looks like a .NET 10 servicing timing glitch, fails looking for 10.0.15. Will retry in an hour or so.

[JulieLeeMSFT]

Will probably want to backport this.

The author said that backport would work for them. We can skip backports.

Did you mean to write "will not"? I think we should consider fixing this...

I mean workaround works for them -- #137063 (comment).

[AndyAyersMS]

/azp run runtime

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).