Add a getIndirectSize API to the JIT-EE interface to represent the correct size for ldobj/stobj operations #123740
+192
−23
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
area-CodeGen-coreclr
Contributor
|
Tagging subscribers to this area: @JulieLeeMSFT, @dotnet/jit-contrib |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds a new getClassIndirectSize API to the JIT-EE interface to support accurate indirect load/store operations for types with special layout characteristics, particularly Swift structs and enums. These types have different sizes when accessed indirectly (excluding trailing padding) versus their full stride (including padding).
Changes:
- Adds
getClassIndirectSizemethod to the JIT-EE interface (ICorStaticInfo) - Implements the new API in CoreCLR VM and NativeAOT (currently returning the same value as
getClassSizefor zero-diff behavior) - Updates JIT to use
IndirectSize()instead ofSize()for block operations (ldobj/stobj) - Adds full superpmi support for recording and replaying the new API call
- Updates JITEEVERSIONGUID to reflect the interface change
Reviewed changes
Copilot reviewed 32 out of 32 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/coreclr/inc/corinfo.h | Adds virtual method declaration for getClassIndirectSize |
| src/coreclr/inc/jiteeversionguid.h | Updates GUID to reflect JIT-EE interface change |
| src/coreclr/inc/icorjitinfoimpl_generated.h | Adds override declaration |
| src/coreclr/vm/jitinterface.cpp | Implements getClassIndirectSize returning VMClsHnd.GetSize() (same as getClassSize); minor whitespace cleanup |
| src/coreclr/jit/ICorJitInfo_wrapper_generated.hpp | Adds wrapper implementation |
| src/coreclr/jit/ICorJitInfo_names_generated.h | Adds API name for diagnostics |
| src/coreclr/jit/layout.h | Adds m_indirectSize field and GetIndirectSize() accessor |
| src/coreclr/jit/layout.cpp | Fetches and stores indirect size via new API call |
| src/coreclr/jit/gentree.h | Adds IndirectSize() method to GenTreeBlk |
| src/coreclr/jit/gentree.cpp | Updates GenTreeIndir::Size() to use IndirectSize() for block operations |
| src/coreclr/jit/valuenum.cpp | Uses IndirectSize() for value numbering block loads |
| src/coreclr/jit/lsra*.cpp | Updates BuildBlockStore to use IndirectSize() across all architectures |
| src/coreclr/jit/lower*.cpp | Updates LowerBlockStore to use IndirectSize() across all architectures; updates helper call lowering |
| src/coreclr/jit/codegenlinear.cpp | Uses IndirectSize() for setting block size in register |
| src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs | Implements getClassIndirectSize returning GetElementSize() (same as getClassSize) |
| src/coreclr/tools/Common/JitInterface/CorInfoImpl_generated.cs | Adds generated callback and delegate for new API |
| src/coreclr/tools/Common/JitInterface/ThunkGenerator/ThunkInput.txt | Adds function signature for thunk generation |
| src/coreclr/tools/aot/jitinterface/jitinterface_generated.h | Adds callback and wrapper implementation |
| src/coreclr/tools/superpmi/superpmi/icorjitinfo.cpp | Adds replay support |
| src/coreclr/tools/superpmi/superpmi-shim-simple/icorjitinfo_generated.cpp | Adds passthrough interceptor |
| src/coreclr/tools/superpmi/superpmi-shim-counter/icorjitinfo_generated.cpp | Adds counting interceptor |
| src/coreclr/tools/superpmi/superpmi-shim-collector/icorjitinfo.cpp | Adds recording interceptor |
| src/coreclr/tools/superpmi/superpmi-shared/methodcontext.h | Adds method declarations and packet enum |
| src/coreclr/tools/superpmi/superpmi-shared/methodcontext.cpp | Implements record/dump/replay methods |
| src/coreclr/tools/superpmi/superpmi-shared/lwmlist.h | Adds LightWeightMap entry for the new API |
Member
|
This concept feels unnatural on the JIT side. Almost everything deals with this size while almost nothing deals with stride as the concept (mostly element address calculations?). Is there a reason why we cannot introduce stride as the concept? (Also, I expect we would not need a new JIT-EE API to compute the stride from the size and alignment.) |
jkotas
reviewed
Jan 29, 2026
| CORINFO_CLASS_HANDLE cls | ||
| ) = 0; | ||
|
|
||
| // return the number of bytes needed by an instance of the class when accessed indirectly |
Member
There was a problem hiding this comment.
This comment should explain what "accessed indirectly" means exactly, an example would be nice.
This was referenced Jan 29, 2026
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We will use this to represent accurate indirect loads/stores for structs with ExtendedLayoutKind.SwiftStruct and ExtendedLayoutKind.SwiftEnum. These types have no trailing padding themselves, but their stride includes trailing padding.
I believe this is the easiest way to represent this without breaking requiring special handling for System.Span and the like.
Adding this in a separate PR to be a zero-diff change.
After this PR, I'll put out a PR to update the VMs to correctly handle layout (including recursive layout) for types with Swift layout.
Contributes to #100896