[mono][interp] Intrinsify Vector128 GetElement/WithElement on wasm

[lewing]

Summary

The Mono interpreter did not recognize Vector128<T>.GetElement or Vector128<T>.WithElement, so every lane access fell back to the managed implementation. On browser-wasm that costs a 16-byte vector copy to the stack, address arithmetic, and an indirect load — for a single lane read.

System.Numerics leans on these APIs heavily (~120 GetElement and ~66 WithElement call sites), so the overhead is visible in Matrix4x4 and Quaternion code.

The PackedSimd ExtractScalar/ReplaceScalar interpreter intrinsics already implement exactly this operation, so this maps the two methods onto them. No new MINT opcodes, no new interp-simd helpers, and no jiterpreter changes — the existing simdExtractTable/simdReplaceTable already lower these to wasm extract_lane/replace_lane.

Preserving ArgumentOutOfRangeException

The public APIs throw ArgumentOutOfRangeException for an out-of-range lane, but interpreter SIMD intrinsics are plain C helpers that cannot raise a managed exception. Worse, the underlying helper masks the lane index rather than checking it:

// interp-simd.c#defineWRAP_LANE(lane_type, lane_ptr) \
(*((unsigned char *)lane_ptr) & (LANE_COUNT(lane_type) - 1))

That reads only the low byte and masks, so a naive lowering would make GetElement(-1) silently return lane 15 instead of throwing.

So this intrinsifies only when the index is a compile-time constant provably in [0, laneCount), which makes the mask a provable no-op. Every other case — a variable index, or an out-of-range constant — returns FALSE so the managed implementation runs and throws.

That restriction is also what the jiterpreter needs independently, since the wasm extract_lane/replace_lane opcodes take the lane as an immediate. A non-constant lane would truncate the trace rather than produce vectorized code. (Trace truncation is a perf loss only, never a behavior change.)

MONO_TYPE_CHAR and any non-primitive fall through to default: and are not intrinsified. ExtractScalar I1/U1/I2/U2 sign/zero-extend to match the interpreter's I4 stack slot; WithElement uses the signedness-agnostic ReplaceScalarD* helpers.

Table ordering fix (required, not cosmetic)

sri_vector128_methods[] is searched with mono_binary_search, so it must be strictly sorted. SN_AsVector4 and SN_AsVector128 were already inverted on main (leaving AsVector4 unreachable). Because probe positions depend on the array length, adding entries would have shifted the problem onto AsVector128. Reordering to SN_AsVector, SN_AsVector128, SN_AsVector4 yields zero unreachable entries, verified by simulating the binary search over the whole table.

Measurements

Browser-wasm Release, V8, median ns/op. 3 BEFORE + 3 AFTER runs; medians stable across runs (e.g. WithElement BEFORE 2.876/2.873/2.875 → AFTER 1.767/1.755/1.775).

Benchmark	BEFORE	AFTER	Δ
Vector128<float>.WithElement(2)	2.8750	1.7750	−38.3%
Matrix4x4.CreateFromQuaternion	39.4220	32.3500	−17.9%
Vector128<byte>.GetElement(11)	1.2670	1.0470	−17.4%
Vector128<int>.GetElement(3)	1.2880	1.0750	−16.5%
Quaternion.CreateFromRotationMatrix	42.3440	38.0780	−10.1%
Matrix4x4.Decompose	253.5400	242.1500	−4.5%
Vector3.Transform(matrix)	69.2000	67.2680	−2.8%
Plane.CreateFromVertices	56.0860	55.9080	−0.3%

dotnet.native.wasm grows by 329 bytes (3,158,305 → 3,158,634).

One lambda-based benchmark in the first-listed slot measured +6.8%, which I chased rather than dismissed. A dedicated [MethodImpl(NoInlining)] static loop performing the identical operation measures −7.7% (FloatExtractLoop) and −11.2% (IntExtractLoop), and its IR shows the expected opcode collapse — so the outlier is a first-benchmark warmup artifact, not a regression. Recording it for completeness.

Interpreter IR for the extract, before and after

BEFORE — 5 opcodes, including a 16-byte vector copy:

IR_0014: mov.vt [48 <- 0], 16 <- 16-byte vector copy
IR_0018: ldloca.s [64 <- nil], 48
IR_001c: add.i4.imm [64 <- 64], 8
IR_0020: ldind.r4 [64 <- 64],
IR_0023: add.r4 [32 <- 32 64],

AFTER — 2 opcodes, no vector copy:

IR_0014: ldc.i4.s [48 <- nil], 2
IR_0017: simd_intrins_p_pp [48 <- 0 48], 57 <- 57 = ExtractScalarR4
IR_001c: add.r4 [32 <- 32 48],

The ldc.i4.s sits immediately before the SIMD instruction that reads it, so the jiterpreter's get_known_constant_value recovers the lane and emits a real extract_lane.

Testing

Four new tests in Vector128Tests.cs. The existing GetElement tests all use loop-variable indices, so none of them exercised the new constant path, and the project had noArgumentOutOfRangeException coverage at all:

• Vector128GetElementConstantIndexTest / Vector128WithElementConstantIndexTest — literal indices across all 12 element types, covering sign-extension (-1, -128, short.MinValue), zero-extension (255, 65535), and -0.0/NaN/NegativeInfinity. Negative zero is compared by bit pattern via BitConverter.*Bits, matching the existing TestConstant<T> helper, since Assert.Equal would treat -0.0 == +0.0 as equal.
• Vector128GetElementOutOfRangeTest — out-of-range constant indices must still throw for both APIs.
• Vector128GetElementVariableOutOfRangeTest — [Theory] over -1, 4, int.MaxValue, int.MinValue.

[Fact] with literal indices is deliberate here: a [Theory] parameter is not a compile-time constant and would silently stop covering the lowered path.

Results:

• Browser/WASM build and native osx-arm64 Mono build: clean, 0 warnings, 0 errors.
• 13028/13028 tests pass in System.Runtime.Intrinsics.Tests on browser-wasm/V8.
• Verified via MONO_VERBOSE_METHOD IR dumps that constant-index cases emit simd_intrins_p_pp/_ppp with zero managed calls, while out-of-range and variable-index cases emit zero SIMD intrinsics and still throw. No "Non-constant lane index" or "out of range" jiterpreter errors across the full 13028-test log.

Notes for reviewers

• Non-wasm hosts are unaffected: the new IDs are in the lookup table unconditionally but hit default: return FALSE with no mutation of td, and the ExtractScalar*/ReplaceScalar* enum values only exist under HOST_BROWSER/HOST_WASI, which is why the new cases carry that guard.
• Separate pre-existing bug, not fixed here: packedsimd_alias_methods[] has four unreachable entries (Store, StoreUnsafe, Subtract, SubtractSaturate) because Sqrt is sorted after SubtractSaturate. Happy to file it separately.

Note

This pull request description was generated by GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 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]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR updates the Mono interpreter’s SIMD intrinsic expansion to recognize Vector128<T>.GetElement and Vector128<T>.WithElement and lower them (on HOST_BROWSER/HOST_WASI) to existing PackedSimd extract/replace scalar helpers when the lane index is a provable in-range constant, while preserving ArgumentOutOfRangeException behavior by falling back to the managed implementation otherwise.

Changes:

• Fixes sri_vector128_methods[] ordering to keep mono_binary_search correct and adds GetElement/WithElement to the searchable method set.
• Adds wasm-only intrinsic expansion for SN_GetElement/SN_WithElement, gated on a basic-block-local constant-index check.
• Adds new unit tests that explicitly exercise constant-index behavior and out-of-range/variable-index exception behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/mono/mono/mini/interp/transform-simd.c	Fixes intrinsic lookup table ordering and adds wasm/WASI lowering for GetElement/WithElement with a constant in-range lane guard.
src/mono/mono/mini/interp/simd-methods.def	Adds GetElement and WithElement to the SIMD method name table used for intrinsic lookup.
src/libraries/System.Runtime.Intrinsics/tests/Vectors/Vector128Tests.cs	Adds tests covering constant-index extraction/replacement and ensuring out-of-range/variable indices still throw.