Pull request overview

This PR extends CoreCLR JIT “exact context” tracking so that calls with shared generic return types can later recover a more precise return type (avoiding __Canon), enabling improved downstream optimizations (e.g., devirtualization / inlining decisions based on sharper types).

Changes:

• Introduces ExactContextInfo (renamed from LateDevirtualizationInfo) and stores it on GT_CALL nodes for virtual calls and certain shared-generic-return calls.
• Uses the saved exact context in gtGetClassHandle to query the EE for a more precise call return type.
• Adjusts NativeAOT/CoreCLR tooling JitInterface logic around method signature instantiation and callsite-specific intrinsic expansion context.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.

                    else if (type is InstantiatedType instantiatedType && method.OwningType.HasSameTypeDefinition(instantiatedType))
                    {
                        Instantiation methodInst = method.Instantiation;
                        method = _compilation.TypeSystemContext.GetMethodForInstantiatedType(method.GetTypicalMethodDefinition(), instantiatedType);
                        if (methodInst.Length > 0)
                        {
                            method = method.MakeInstantiatedMethod(methodInst);
                        }
                    }

Holistic Review

Motivation: When the JIT queries a call's return type via gtGetClassHandle for a user call, it previously discarded the exact generic context, so for shared generic instantiations it could only recover an approximate (canonical) return type. This blocks type-driven optimizations on values flowing out of such calls. The PR revives the earlier attempt (#100041) to preserve the exact context so the precise return type is available. Example improvement: (compilerexplorer.com/redacted)

Approach: The existing per-call LateDevirtualizationInfo side structure is generalized and renamed to ExactContextInfo (gtLateDevirtualizationInfo -> gtExactContextInfo). It is now populated not only for devirtualization candidates but also for calls whose signature return type is a shared instantiation (eeIsSharedInst(sig->retTypeSigClass), excluding byrefs). A new eeGetMethodFromContext helper factors the method-context decoding out of eeGetClassFromContext. gtGetClassHandle consumes the saved context to compute an exactClass (and, for method contexts, an exact method) before calling eeGetMethodSig, yielding the precise return type. The RyuJit AOT getCallInfo path is updated to set contextHandle when intrinsic-for-callsite expansion swaps the target method, so the JIT sees a consistent exact context in that case.

Summary: The change is well-scoped and internally consistent. The rename is applied uniformly (no stale LateDevirtualizationInfo references remain), gtExactContextInfo is initialized in gtNewCallNode and copied in gtCloneExprCallHelper, and the unconditional deref in LateDevirtualization remains safe because the field is still always set for devirtualization candidates. All new reads outside that path are null-guarded, and eeGetMethodFromContext asserts its context encoding. The main residual risk is correctness of the newly-derived exact return types across the full generics matrix (CoreCLR and NativeAOT) — the author noted encountering asserts while iterating — so this is primarily validated by broad JIT/pri1 and NativeAOT CI coverage rather than by review of the diff alone. No blocking issues found in the changed lines. Verdict: LGTM pending green CI.

Detailed Findings

No actionable defects identified in the changed lines. Observations:

• gtGetClassHandle (src/coreclr/jit/gentree.cpp): for a CLASS-flagged context, method remains the (canonical) gtCallMethHnd while exactClass is set from the context; for a METHOD-flagged context both method and exactClass are refined. This asymmetry is intentional and correct, but relies on eeGetMethodSig producing the exact return type from the approximate method + exact class in the CLASS case; worth confirming via CI on shared value-type instantiations.
• The sig->retType != CORINFO_TYPE_BYREF exclusion in importercalls.cpp is a reasonable guard (byref-returning shared generics don't yield a usable return class), but is undocumented; a brief comment on why byref is excluded would aid future readers.
• The NativeAOT getCallInfo change asserts !exactContextNeedsRuntimeLookup and no instantiations on the intrinsic-expansion swap path; these assumptions look sound for the ExpandIntrinsicForCallsite cases but are the most AOT-specific part of the change and should be exercised by the NativeAOT test legs.

Generated by Holistic Review · 69.6 AIC · ⌖ 10.5 AIC · ⊞ 10K