Merged
Conversation
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 pull request fixes a critical JIT crash (access violation) in LowerCallMemmove that occurs when compiling calls to C++/CLI functions returning structs with aggregate initialization, addressing issue #123748.
Changes:
- Fixed
LowerCallMemmoveinsrc/coreclr/jit/lower.cppto use proper helper functions (gtNewBlkIndirandgtNewStoreBlkNode) instead of manual tree construction - Corrected the
*nextpointer to point to the first node to be lowered (srcBlk) instead of accessing an uninitializedgtNextfield - Added explicit
GTF_IND_UNALIGNEDtoGTF_IND_FLAGSinsrc/coreclr/jit/gentree.h(redundant but harmless)
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/coreclr/jit/lower.cpp | Fixed the LowerCallMemmove function to use proper helper functions for tree construction and corrected the next pointer to avoid null dereference |
| src/coreclr/jit/gentree.h | Added GTF_IND_UNALIGNED explicitly to GTF_IND_FLAGS (redundant as it's already included via GTF_IND_COPYABLE_FLAGS) |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This was referenced Feb 3, 2026
…move-lowering # Conflicts: # src/coreclr/jit/lower.cpp
…move-lowering # Conflicts: # src/coreclr/jit/lower.cpp
This was referenced Feb 9, 2026
2 tasks
Member
Author
|
PTAL @dotnet/jit-contrib simple fix for a potential problem |
jakobbotsch
approved these changes
Feb 11, 2026
iremyux
pushed a commit
to iremyux/dotnet-runtime
that referenced
this pull request
Mar 2, 2026
Might fix (but not sure) dotnet#123748 `LowerCallMemmove` was initially written to inline `SpanHelpers.Memmove` into something that guarantees proper non-aliased move (load all data into separate registers first, then save them all at once) as opposite to what normal `GT_STORE_BLK` does - it's paired with `genCodeForMemmove`. That's why we sort of try to Lower BLK/STORE_BLK by hands there. Later, `CORINFO_HELP_MEMCPY` was added as well (typical scenario: `cpblk` IL code (`Unsafe.CopyBlocksUnaligned`) with the length that becomes a constant in a late phase) and since it doesn't require the memmove semantics, we used `GenTreeBlk::BlkOpKindUnroll`, but in that case we either have to replace the call into a pre-Lower shape and call Lower on srcBlk+storeBlk since we're no longer paired with `genCodeForMemmove`, or just use the same memmove mode. `memmove` mode is more expensive for LSRA and doesn't support addressing modes, but it seems that `CORINFO_HELP_MEMCPY` is rarely used. Example of a changed codegen: ```cs static void Test(ref byte a, ref byte b, uint len) { if (len == 200) { Unsafe.CopyBlockUnaligned(ref a, ref b, len); } } ``` Was: ```asm vmovdqu32 zmm0, zmmword ptr [rdx] vmovdqu32 zmmword ptr [rcx], zmm0 vmovdqu32 zmm0, zmmword ptr [rdx+0x40] vmovdqu32 zmmword ptr [rcx+0x40], zmm0 vmovdqu32 zmm0, zmmword ptr [rdx+0x80] vmovdqu32 zmmword ptr [rcx+0x80], zmm0 mov rax, qword ptr [rdx+0xC0] mov qword ptr [rcx+0xC0], rax ``` Now: ```asm vmovdqu32 zmm0, zmmword ptr [rdx] vmovdqu32 zmm1, zmmword ptr [rdx+0x40] vmovdqu32 zmm2, zmmword ptr [rdx+0x80] vmovdqu xmm3, xmmword ptr [rdx+0xB8] vmovdqu32 zmmword ptr [rcx], zmm0 vmovdqu32 zmmword ptr [rcx+0x40], zmm1 vmovdqu32 zmmword ptr [rcx+0x80], zmm2 vmovdqu xmmword ptr [rcx+0xB8], xmm3 ``` No [diffs](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1287687&view=ms.vss-build-web.run-extensions-tab) --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Might fix (but not sure) #123748
LowerCallMemmovewas initially written to inlineSpanHelpers.Memmoveinto something that guarantees proper non-aliased move (load all data into separate registers first, then save them all at once) as opposite to what normalGT_STORE_BLKdoes - it's paired withgenCodeForMemmove. That's why we sort of try to Lower BLK/STORE_BLK by hands there.Later,
CORINFO_HELP_MEMCPYwas added as well (typical scenario:cpblkIL code (Unsafe.CopyBlocksUnaligned) with the length that becomes a constant in a late phase) and since it doesn't require the memmove semantics, we usedGenTreeBlk::BlkOpKindUnroll, but in that case we either have to replace the call into a pre-Lower shape and call Lower on srcBlk+storeBlk since we're no longer paired withgenCodeForMemmove, or just use the same memmove mode.memmovemode is more expensive for LSRA and doesn't support addressing modes, but it seems thatCORINFO_HELP_MEMCPYis rarely used.Example of a changed codegen:
Was:
Now:
No diffs