feat(rv32): implement i64 SIMD polyfill via register-pair calling convention

[cschanhniem]

Context

The RISC-V backend currently has an open issue (#295) about i64.div_s/rem_s sign computation being clobbered by the udiv cores fixed registers. Beyond that specific bug, the RV32 backend generally lacks i64 SIMD-level throughput because there is no polyfill path that maps WASM v128 (SIMD) operations onto the RV32P Zve32* or Zvl32* vector extensions.

Proposal

Implement a compile-time --rv32-simd=zve32x|zve32f|zvl32b option that enables v128 lowering via subregister pairing:

WASM op	RV32 lowering	Extension needed
v128.load / v128.store	4× i32 scalar	Zve32x (base)
i8x16.add	16× byte SIMD via vadd.vv EEW=8	Zve32x
i16x8.add	8× halfword via vadd.vv EEW=16	Zve32x
i32x4.add	4× word via vadd.vv EEW=32	Zve32x
i64x2.add	2× doubleword via vadd.vv EEW=64	Zve64x (requires Zvl64b)
f32x4.add	4× float via vfadd.vv	Zve32f

When the target does not advertise Zve64x (common on RV32 embedded cores like the GD32V), i64x2 ops degrade to 2× scalar i64 register pairs — the same pattern already used for scalar i64 in the rv32 backend.

Rationale

WASM SIMD is one of the most impactful proposals for embedded/edge workloads (sensor fusion, audio DSP, pixel ops). Synth targets Cortex-M and RV32 equally in its mission statement; adding RV32 SIMD lowering closes the functional gap with the ARM backend, which already has NEON-adjacent ops via VFP/ASIMD.

Existing precedent in the codebase

• Synth already has --relocatable and --safety-bounds target options (cleanup(riscv): allocator prefers caller-saved (lowest-free, not round-robin) (#230, v0.11.26) #231, fix(encoder): ORR/EOR immediate emit the real instruction, not a silent NOP (VCR-RA-001) #251).
• The arm backend selects between Thumb, Thumb-2, and ARM ISA based on target triple. RISC-V should similarly select between RV32I, RV32IM, and Zve* based on --rv32-simd= or a target-feature string.
• Several open proof tickets (VCR-* epic) and the Rocq/Rust divergence (docs: binary safety checks design — ARM + RISC-V opt-in safety profiles #110) already discuss adding new lowering rules with proof obligations. SIMD lowering could start with the non-proof path (like the current unproven i64/float path) and be proven later.

Minimal first step

A single PR that:

1. Adds RiscvSimdLevel to the target configuration
2. Lowers i8x16.splat, i8x16.extract_lane, and i8x16.replace_lane to vmv.v.x / vget.v / vset.v
3. Wires these through the existing test harness and verifies against 5 SIMD spec tests

This is analogous to how the arm backend incrementally added f32 support.

[avrabe]

[synth maintainer side — issue-hunt triage] Thanks for the detailed proposal, and welcome. The direction — RV32 SIMD lowering to close the v128 gap with the ARM path — is legitimately in scope (synth does target Cortex-M and RV32 equally). But before this can be scheduled, a few corrections and prerequisites, because the issue as written rests on some inaccurate references:

Reference corrections (every cited issue maps to something else, so please re-ground these):

• chore(deps): bump z3 from 0.19.7 to 0.19.15 #295 is chore(deps): bump z3, not i64.div_s/rem_s. The real open RV32 sign-clobber bug is rv32: i64.div_s/rem_s sign computation clobbered by the udiv core's fixed registers — wrong signs (pre-existing) #317.
• cleanup(riscv): allocator prefers caller-saved (lowest-free, not round-robin) (#230, v0.11.26) #231 is cleanup(riscv): allocator prefers caller-saved; fix(encoder): ORR/EOR immediate emit the real instruction, not a silent NOP (VCR-RA-001) #251 is an ORR/EOR encoder fix — neither is --relocatable/--safety-bounds (those are v0.11.9: pointer param live across calls not preserved in a complex/register-heavy fn (sem read from 0x20000100+clobbered r0) — minimal cases pass (follow-up to #188) #197 and the Phase-1 binary-safety work).
• docs: binary safety checks design — ARM + RISC-V opt-in safety profiles #110 is the binary-safety design doc; the Rocq↔Rust divergence is proof: Rocq compile_wasm_to_arm diverges from Rust instruction selector #73.

Technical notes:

• RV32P (packed-SIMD) and Zve32*/Zvl* (the RISC-V Vector embedded subsets) are different, non-interchangeable extension families — the table needs to commit to one (the V/Zve path is the live one).
• The ARM side has no NEON/ASIMD — those are A-profile. synth's v128 lowering targets Helium/MVE (Cortex-M55); there's no "NEON-adjacent via VFP/ASIMD" to mirror.

Prerequisites (why this isn't next): the RV32 backend still has foundational correctness gaps that precede SIMD — #317 (i64 div sign), #343 (if/else-with-result has no result-register reconciliation), and it's effectively leaf-focused with op gaps. Adding a vector path on top of a backend that can't yet reconcile an if/else result would be building on sand. The release cadence is also driven by concrete on-target consumer needs (the current flight/embedded workloads); I don't yet have a consumer asking for RV32 vector throughput.

To move this forward, two things would help: (1) a concrete use-case/consumer with a measured workload that needs RV32 SIMD (so the benefit is quantified, not assumed), and (2) it lands behind the VCR-* proof-obligation discipline like every other new lowering. Until then I'm classifying this feature / needs-demand-signal / deferred rather than scheduling it. Happy to revisit when #317 + #343 are closed and there's a real workload — and a focused first PR (e.g. just i8x16.splat/extract/replace) would be a reasonable starting point at that time.