JIT: Fix WASM scalar extraction from SIMD parameters by lewing · Pull Request #131237 · dotnet/runtime

lewing · 2026-07-22T21:54:30Z

Summary

Fixes a WASM codegen bug where extracting a scalar field from a SIMD-register parameter leaks a v128 where a scalar (f64/f32/...) is expected, producing invalid WASM:

type mismatch: expected f64, found v128

Lowering::FindInducedParameterRegisterLocals maps 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 distinct v128 and scalar value-stack types and cannot reinterpret them implicitly.

This is the floating-point ToScalar / SIMD-to-scalar var_type transition at ABI boundaries noted as deferred in #130444.

Fix

When the mapped incoming register local is SIMD and the field is scalar, use gtNewSimdGetElementNode under TARGET_WASM. For lane zero this becomes ToScalar, which WASM lowers to the appropriate extract_lane operation rather than retyping a v128 local 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 Debug
PATH="/opt/homebrew/bin:$PATH" ./build.sh -os browser -c Debug -subset clr+libs
- Confirmed lower.cpp compiled into the WASM JIT.
python3 src/coreclr/scripts/jitformat.py -r . -o osx -a arm64

There 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.

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 · 2026-07-22T21:55:15Z

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.

dotnet-policy-service · 2026-07-22T21:55:39Z

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

Copilot

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 in Lowering::FindInducedParameterRegisterLocals to use gtNewSimdGetElementNode when extracting a scalar from a SIMD local.
Preserve the existing behavior for non-WASM targets.

lewing · 2026-07-23T02:28:55Z

/ba-g infra failures outside the platform guard on this pr

lewing · 2026-07-22T21:54:30Z

Summary

Fixes a WASM codegen bug where extracting a scalar field from a SIMD-register parameter leaks a v128 where a scalar (f64/f32/...) is expected, producing invalid WASM:

type mismatch: expected f64, found v128

Lowering::FindInducedParameterRegisterLocals maps 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 distinct v128 and scalar value-stack types and cannot reinterpret them implicitly.

This is the floating-point ToScalar / SIMD-to-scalar var_type transition at ABI boundaries noted as deferred in #130444.

Fix

When the mapped incoming register local is SIMD and the field is scalar, use gtNewSimdGetElementNode under TARGET_WASM. For lane zero this becomes ToScalar, which WASM lowers to the appropriate extract_lane operation rather than retyping a v128 local 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 Debug
PATH="/opt/homebrew/bin:$PATH" ./build.sh -os browser -c Debug -subset clr+libs
- Confirmed lower.cpp compiled into the WASM JIT.
python3 src/coreclr/scripts/jitformat.py -r . -o osx -a arm64

There 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.

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 · 2026-07-22T21:55:15Z

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.

dotnet-policy-service · 2026-07-22T21:55:39Z

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

Copilot

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 in Lowering::FindInducedParameterRegisterLocals to use gtNewSimdGetElementNode when extracting a scalar from a SIMD local.
Preserve the existing behavior for non-WASM targets.

lewing · 2026-07-23T02:28:55Z

/ba-g infra failures outside the platform guard on this pr

lewing · 2026-07-22T21:54:30Z

Summary

Fixes a WASM codegen bug where extracting a scalar field from a SIMD-register parameter leaks a v128 where a scalar (f64/f32/...) is expected, producing invalid WASM:

type mismatch: expected f64, found v128

Lowering::FindInducedParameterRegisterLocals maps 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 distinct v128 and scalar value-stack types and cannot reinterpret them implicitly.

This is the floating-point ToScalar / SIMD-to-scalar var_type transition at ABI boundaries noted as deferred in #130444.

Fix

When the mapped incoming register local is SIMD and the field is scalar, use gtNewSimdGetElementNode under TARGET_WASM. For lane zero this becomes ToScalar, which WASM lowers to the appropriate extract_lane operation rather than retyping a v128 local 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 Debug
PATH="/opt/homebrew/bin:$PATH" ./build.sh -os browser -c Debug -subset clr+libs
- Confirmed lower.cpp compiled into the WASM JIT.
python3 src/coreclr/scripts/jitformat.py -r . -o osx -a arm64

There 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.

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 · 2026-07-22T21:55:15Z

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.

dotnet-policy-service · 2026-07-22T21:55:39Z

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

Copilot

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 in Lowering::FindInducedParameterRegisterLocals to use gtNewSimdGetElementNode when extracting a scalar from a SIMD local.
Preserve the existing behavior for non-WASM targets.

lewing · 2026-07-23T02:28:55Z

/ba-g infra failures outside the platform guard on this pr

lewing · 2026-07-22T21:54:30Z

Summary

Fixes a WASM codegen bug where extracting a scalar field from a SIMD-register parameter leaks a v128 where a scalar (f64/f32/...) is expected, producing invalid WASM:

type mismatch: expected f64, found v128

Lowering::FindInducedParameterRegisterLocals maps 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 distinct v128 and scalar value-stack types and cannot reinterpret them implicitly.

This is the floating-point ToScalar / SIMD-to-scalar var_type transition at ABI boundaries noted as deferred in #130444.

Fix

When the mapped incoming register local is SIMD and the field is scalar, use gtNewSimdGetElementNode under TARGET_WASM. For lane zero this becomes ToScalar, which WASM lowers to the appropriate extract_lane operation rather than retyping a v128 local 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 Debug
PATH="/opt/homebrew/bin:$PATH" ./build.sh -os browser -c Debug -subset clr+libs
- Confirmed lower.cpp compiled into the WASM JIT.
python3 src/coreclr/scripts/jitformat.py -r . -o osx -a arm64

There 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.

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 · 2026-07-22T21:55:15Z

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.

dotnet-policy-service · 2026-07-22T21:55:39Z

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

Copilot

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 in Lowering::FindInducedParameterRegisterLocals to use gtNewSimdGetElementNode when extracting a scalar from a SIMD local.
Preserve the existing behavior for non-WASM targets.

lewing · 2026-07-23T02:28:55Z

/ba-g infra failures outside the platform guard on this pr

lewing · 2026-07-22T21:54:30Z

Summary

Fixes a WASM codegen bug where extracting a scalar field from a SIMD-register parameter leaks a v128 where a scalar (f64/f32/...) is expected, producing invalid WASM:

type mismatch: expected f64, found v128

Lowering::FindInducedParameterRegisterLocals maps 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 distinct v128 and scalar value-stack types and cannot reinterpret them implicitly.

This is the floating-point ToScalar / SIMD-to-scalar var_type transition at ABI boundaries noted as deferred in #130444.

Fix

When the mapped incoming register local is SIMD and the field is scalar, use gtNewSimdGetElementNode under TARGET_WASM. For lane zero this becomes ToScalar, which WASM lowers to the appropriate extract_lane operation rather than retyping a v128 local 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 Debug
PATH="/opt/homebrew/bin:$PATH" ./build.sh -os browser -c Debug -subset clr+libs
- Confirmed lower.cpp compiled into the WASM JIT.
python3 src/coreclr/scripts/jitformat.py -r . -o osx -a arm64

There 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.

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 · 2026-07-22T21:55:15Z

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.

dotnet-policy-service · 2026-07-22T21:55:39Z

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

Copilot

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 in Lowering::FindInducedParameterRegisterLocals to use gtNewSimdGetElementNode when extracting a scalar from a SIMD local.
Preserve the existing behavior for non-WASM targets.

lewing · 2026-07-23T02:28:55Z

/ba-g infra failures outside the platform guard on this pr

lewing · 2026-07-22T21:54:30Z

Summary

Fixes a WASM codegen bug where extracting a scalar field from a SIMD-register parameter leaks a v128 where a scalar (f64/f32/...) is expected, producing invalid WASM:

type mismatch: expected f64, found v128

Lowering::FindInducedParameterRegisterLocals maps 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 distinct v128 and scalar value-stack types and cannot reinterpret them implicitly.

This is the floating-point ToScalar / SIMD-to-scalar var_type transition at ABI boundaries noted as deferred in #130444.

Fix

When the mapped incoming register local is SIMD and the field is scalar, use gtNewSimdGetElementNode under TARGET_WASM. For lane zero this becomes ToScalar, which WASM lowers to the appropriate extract_lane operation rather than retyping a v128 local 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 Debug
PATH="/opt/homebrew/bin:$PATH" ./build.sh -os browser -c Debug -subset clr+libs
- Confirmed lower.cpp compiled into the WASM JIT.
python3 src/coreclr/scripts/jitformat.py -r . -o osx -a arm64

There 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.

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 · 2026-07-22T21:55:15Z

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.

dotnet-policy-service · 2026-07-22T21:55:39Z

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

Copilot

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 in Lowering::FindInducedParameterRegisterLocals to use gtNewSimdGetElementNode when extracting a scalar from a SIMD local.
Preserve the existing behavior for non-WASM targets.

lewing · 2026-07-23T02:28:55Z

/ba-g infra failures outside the platform guard on this pr

lewing · 2026-07-22T21:54:30Z

Summary

Fixes a WASM codegen bug where extracting a scalar field from a SIMD-register parameter leaks a v128 where a scalar (f64/f32/...) is expected, producing invalid WASM:

type mismatch: expected f64, found v128

Lowering::FindInducedParameterRegisterLocals maps 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 distinct v128 and scalar value-stack types and cannot reinterpret them implicitly.

This is the floating-point ToScalar / SIMD-to-scalar var_type transition at ABI boundaries noted as deferred in #130444.

Fix

When the mapped incoming register local is SIMD and the field is scalar, use gtNewSimdGetElementNode under TARGET_WASM. For lane zero this becomes ToScalar, which WASM lowers to the appropriate extract_lane operation rather than retyping a v128 local 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 Debug
PATH="/opt/homebrew/bin:$PATH" ./build.sh -os browser -c Debug -subset clr+libs
- Confirmed lower.cpp compiled into the WASM JIT.
python3 src/coreclr/scripts/jitformat.py -r . -o osx -a arm64

There 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.

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 · 2026-07-22T21:55:15Z

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.

dotnet-policy-service · 2026-07-22T21:55:39Z

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

Copilot

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 in Lowering::FindInducedParameterRegisterLocals to use gtNewSimdGetElementNode when extracting a scalar from a SIMD local.
Preserve the existing behavior for non-WASM targets.

lewing · 2026-07-23T02:28:55Z

/ba-g infra failures outside the platform guard on this pr

lewing · 2026-07-22T21:54:30Z

Summary

Fixes a WASM codegen bug where extracting a scalar field from a SIMD-register parameter leaks a v128 where a scalar (f64/f32/...) is expected, producing invalid WASM:

type mismatch: expected f64, found v128

Lowering::FindInducedParameterRegisterLocals maps 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 distinct v128 and scalar value-stack types and cannot reinterpret them implicitly.

This is the floating-point ToScalar / SIMD-to-scalar var_type transition at ABI boundaries noted as deferred in #130444.

Fix

When the mapped incoming register local is SIMD and the field is scalar, use gtNewSimdGetElementNode under TARGET_WASM. For lane zero this becomes ToScalar, which WASM lowers to the appropriate extract_lane operation rather than retyping a v128 local 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 Debug
PATH="/opt/homebrew/bin:$PATH" ./build.sh -os browser -c Debug -subset clr+libs
- Confirmed lower.cpp compiled into the WASM JIT.
python3 src/coreclr/scripts/jitformat.py -r . -o osx -a arm64

There 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.

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 · 2026-07-22T21:55:15Z

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.

dotnet-policy-service · 2026-07-22T21:55:39Z

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

Copilot

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 in Lowering::FindInducedParameterRegisterLocals to use gtNewSimdGetElementNode when extracting a scalar from a SIMD local.
Preserve the existing behavior for non-WASM targets.

lewing · 2026-07-23T02:28:55Z

/ba-g infra failures outside the platform guard on this pr

CopilotAI review requested due to automatic review settings July 22, 2026 21:54

github-actionsBot added the area-VM-coreclr label Jul 22, 2026

dotnet-policy-serviceBot assigned lewing Jul 22, 2026

Copilotstarted reviewing on behalf of lewing July 22, 2026 21:54 View session

lewing requested a review from tannergooding July 22, 2026 21:55

lewing assigned davidwrighton Jul 22, 2026

lewing unassigned lewing and davidwrighton Jul 22, 2026

lewing requested review from davidwrighton and jakobbotsch July 22, 2026 21:56

CopilotAI reviewed Jul 22, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/lower.cpp

lewing requested a review from AndyAyersMS July 22, 2026 22:03

davidwrighton approved these changes Jul 22, 2026
View reviewed changes

lewing mentioned this pull request Jul 22, 2026
JIT: Improve parameter register field extraction and reconstruction #131174
Open

lewing enabled auto-merge (squash) July 22, 2026 22:39

AndyAyersMS approved these changes Jul 22, 2026
View reviewed changes

jakobbotsch approved these changes Jul 22, 2026
View reviewed changes

tannergooding approved these changes Jul 23, 2026
View reviewed changes

lewing merged commit c8132fb into mainJul 23, 2026
133 of 139 checks passed

lewing deleted the lewing-fix-wasm-simd-scalar-extract branch July 23, 2026 02:29

build-analysisBot mentioned this pull request Jul 23, 2026
XHarness package install failure on iOS due to devicectl NSPOSIXErrorDomain error 49 #123796
Open

dotnet-maestroBot mentioned this pull request Jul 23, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7872
Merged

dotnet-milestone-botBot added this to the 11.0-rc1 milestone Jul 24, 2026

github-actionsBot locked and limited conversation to collaborators Aug 23, 2026