JIT: Fix WASM scalar extraction from SIMD parameters#131237
Merged
Merged
Conversation
Extract scalar fields directly from SIMD parameter-register locals on WASM so v128 values are not retyped as scalar locals. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: e48939ab-dc73-4630-a8ca-72c3b926133a
|
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. |
Contributor
|
Tagging subscribers to this area: @agocke |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates CoreCLR JIT lowering to correctly materialize scalar reads from SIMD-register-backed parameter locals on WebAssembly by generating an explicit SIMD lane extraction rather than relying on native-style “retyping” of a v128 local access into a scalar type.
Changes:
- Add a
TARGET_WASM-specific path inLowering::FindInducedParameterRegisterLocalsto usegtNewSimdGetElementNodewhen extracting a scalar from a SIMD local. - Preserve the existing behavior for non-WASM targets.
davidwrighton
approved these changes
Jul 22, 2026
lewing
enabled auto-merge (squash)
July 22, 2026 22:39
AndyAyersMS
approved these changes
Jul 22, 2026
jakobbotsch
approved these changes
Jul 22, 2026
tannergooding
approved these changes
Jul 23, 2026
Member
Author
|
/ba-g infra failures outside the platform guard on this pr |
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.
Summary
Fixes a WASM codegen bug where extracting a scalar field from a SIMD-register parameter leaks a
v128where a scalar (f64/f32/...) is expected, producing invalid WASM:Lowering::FindInducedParameterRegisterLocalsmaps a scalar field of an unenregisterable parameter to the local created for the containing register segment. Native targets can read the overlapping low scalar value by retyping that local access, but WASM has distinctv128and scalar value-stack types and cannot reinterpret them implicitly.This is the floating-point
ToScalar/ SIMD-to-scalarvar_typetransition at ABI boundaries noted as deferred in #130444.Fix
When the mapped incoming register local is SIMD and the field is scalar, use
gtNewSimdGetElementNodeunderTARGET_WASM. For lane zero this becomesToScalar, which WASM lowers to the appropriateextract_laneoperation rather than retyping av128local or spilling through memory.The byte offset is required to be scalar-lane aligned before deriving the lane index. Every non-WASM target retains the existing path unchanged.
Validation
./build.sh clr.jit -rc DebugPATH="/opt/homebrew/bin:$PATH" ./build.sh -os browser -c Debug -subset clr+libslower.cppcompiled into the WASM JIT.python3 src/coreclr/scripts/jitformat.py -r . -o osx -a arm64There is currently no WASM R2R validation leg in CI suitable for a focused regression test. The existing generalized extraction tests from #131174 were intentionally not included in this narrowly scoped WASM correctness fix.
Note
This PR was authored with the assistance of GitHub Copilot.