Fix SIMD primitive zero initialization - #133100
Conversation
Ensure block morphing replaces the integer zero source with the newly created SIMD zero node. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Azure Pipelines: Successfully started running 5 pipeline(s). 11 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The fix is a minimal, localized correctness change (updating the store operand to match the new SIMD zero node) with targeted regression coverage added.
Review tier: Lite
Findings: None
What changed in this PR
This PR fixes a CoreCLR JIT morphing bug where TryPrimitiveInit could retarget an init-block into a SIMD-typed store but leave the store’s Data() operand pointing at the original integer zero constant, producing an invalid SIMD store source and causing Tier0/FullOpts failures. The change updates the rationalized store node to use the newly created SIMD zero constant and adds a JIT regression test covering Vector128 and Vector256 under both Tier0 and FullOpts behavior.
Changes:
- Fix
MorphInitBlockHelper::TryPrimitiveInitto replace the store’sData()operand when creating a SIMD zero source. - Mark the newly created SIMD zero node as morphed to match surrounding morph-phase conventions.
- Add a JitBlue regression test project validating
Vector128<ulong>andVector256<ulong>zero-init throughUnsafe.As<,>()under tiered compilation.
| File | Description |
|---|---|
| src/coreclr/jit/morphblock.cpp | Updates primitive-init morphing to keep store Data() consistent with a newly created SIMD zero node. |
| src/tests/JIT/Regression/JitBlue/Runtime_133085/Runtime_133085.csproj | Adds a new isolated JIT regression test project with tiered compilation enabled. |
| src/tests/JIT/Regression/JitBlue/Runtime_133085/Runtime_133085.cs | Adds regression coverage for SIMD local zero-init via initobj-equivalent patterns for Vector128/256. |
|
CC. @EgorBo, @jakobbotsch for review. This will need backport to .NET 11 and 10 Fairly old issue and it likely hasn't been hit before due to the exact pattern required to trigger it being a bit unlikely. |
TryPrimitiveInitcreated a SIMD zero node when converting a zero block initialization into a primitive local store, but the rationalized store retained its original integer-zero data node. This produced a SIMD store with an integer source, leading to invalid codegen and Tier0 compilation failures.The missing source replacement was introduced by the assignment rationalization changes in #85585 (
53b4cd0912d), where the legacyGT_ASGpath updatedgtOp2but the rationalized store path did not updateData().Before the fix, the
Vector256case encodedC4 E1 FD 6E C0(vmovqwithVEX.L=1). The corrected tree emits a SIMD zero (vxorps) in both FullOpts and Tier0. Regression coverage includesVector128andVector256in both modes.Fixes #133085
Note
This pull request description was generated with GitHub Copilot.