Port the ARM perf levers (cmp→select, local-promotion, imm-shift-fold) to the RISC-V backend — RV dissolved code is now behind ARM (2.12× vs 1.66× on silicon)

[avrabe]

RISC-V backend lacks the ARM perf levers — dissolved code is now behind ARM (measured on ESP32-C3 silicon)

The VCR-SEL/VCR-RA levers that landed for ARM (cmp→select fusion v0.13.0, i32 local-promotion v0.14.0, immediate-shift folding SYNTH_IMM_SHIFT_FOLD) all live in synth-backend/src/arm_backend.rs. They are not in synth-backend-riscv, so RISC-V dissolved code gets none of them.

Evidence (gust_mix, the synth#428 fixture), synth 0.14.0:

• synth compile … -b riscv --target esp32c3 output is byte-identical with vs without each flag — SYNTH_IMM_SHIFT_FOLD=1, SYNTH_NO_LOCAL_PROMOTE=1, SYNTH_NO_CMP_SELECT_FUSE=1 all produce the same 164 B .o. The flags are ARM-only no-ops on RV32.
• grep SYNTH_ synth-backend-riscv/src → no perf-lever env flags exist.
• v0.13.0 → v0.14.0 left the RISC-V gust_mix unchanged (164 B both).

Impact (real silicon): on the M4 (G474RE, DWT) those four levers took dissolved gust_mix 64.0 → 48.0 cyc/call (2.21× → 1.66× vs LLVM). On the ESP32-C3 (RISC-V RV32IMC, systimer) dissolved gust_mix is still 2.12× — it has the spill/reloads, register-shifts, and materialized-bool clamps the ARM levers eliminated. So RISC-V dissolved codegen is now the lagging backend.

Ask: port the three levers to synth-backend-riscv — they map cleanly to RV32:

• cmp→select → branchless slt/seqz-fed conditional move pattern (or the Zicond czero.* if targeting it; RV32IMC has no cmov, so the materialized-bool→branch idiom is the target).
• local i32 promotion → keep eligible locals in s1–s11 (callee-saved) instead of stack slots — same shape as the ARM r4–r8 promotion.
• immediate-shift folding → slli/srli/srai rd,rs,#C instead of li rM,#C; sll rd,rs,rM.

Validation is ready: gale's ESP32-C3 silicon harness (benches/gust/esp32c3, RISC-V mcycle-less systimer ratio) + the qemu_riscv32 path can run the same flag-off-vs-on DWT-style gate the ARM levers cleared. Happy to re-measure each on the ESP32-C3 as they land — same protocol as the M4 runs in #428.

Refs: synth#428 (the ARM lever tracker + the M4 silicon results); gale benches/gust/esp32c3/RESULTS.md.

[avrabe]

The challenge, grounded: where synth's RV32 codegen loses to LLVM — and where it can beat it

Dug into synth-backend-riscv with the gust_mix disasm in hand. Architecture finding first (the load-bearing one): the ARM levers are not IR-level — they're post-lowering peepholes hard-typed to ArmInstruction/ArmOp (liveness.rs:306,527, wired in arm_backend.rs:455,481,499). The RV backend is a separate pipeline with no pass layer at all: selector.rs::select_with_result_types → backend.rs:146-185 encode_function_bytes, nothing between, no ir_to_riscv, zero SYNTH_* flags. So the levers can't be "shared for free" — RV needs its own selector fixes + a post-lowering pass layer.

The four gaps — origin (file:line) → RV32 fix → portable?

1. Locals spilled to a frame (native: 0 spills, no frame). lower_local_get/set (selector.rs:998,1055) unconditionally Lw/Sw …(sp); preserve_callee_saved opens the frame (selector.rs:282). No promotion path exists (ARM's compute_local_promotion/set_local_promote arm_backend.rs:222 has no RV twin). Fix: promote leaf i32 locals to s1–s11 (esp32c3 has 12 callee-saved). Lowering-level, RV-specific.

2. Clamp as slt → bnez → mv → j → mv (native: direct blt/bge). Comparison lowering (lower_cmp_signed_lt→Slt, selector.rs:1341) and branch/select (lower_select :930, lower_br_if :1687) are decoupled — every i32.lt_s commits a 0/1 bool to a reg, then the consumer re-tests it. Branch::Lt/Ge already exist (riscv_op.rs:21-23). Fix: peephole — comparison immediately consumed by Branch::Ne rd,zero → fuse to blt/bge rs1,rs2,label, drop the bool. Post-lowering peephole, RV-specific (the RV analogue of fuse_cmp_select).

3. Register shifts li t,8; sll (native: slli #8). I32Const always materializes via emit_load_imm into a temp (selector.rs:703), and bin() emits register-form Sll/Sra (selector.rs:739,1184) — the immediate Slli/Srai exist (:1168,2023) but are never reached from the binary path. Fix: a VstackVal::Const(i32) variant so constants stay un-materialized until the consumer picks imm-vs-reg → slli/srai rd,rs,#C. Lowering-level; also fixes #4 and addi/andi/slti.

4. lui;addi;and u16 mask, ×2 (native: subsumed by the slli/srai pair — no mask). 0xffff exceeds addi range → emit_load_imm does lui;addi (selector.rs:3741) then register And (:734). synth never sees that the following slli 8; srai 8 already discards the high bits. Fix: Andi for small consts; for 0xffff narrow via slli 16; srli 16 (2 ops, no scratch); and recognize the mask-subsumed-by-shift-pair idiom (what LLVM does). Mixed: cheap part lowering-level, subsumption is the proof-carrying lever below.

Beat-LLVM (below the 15-instr floor)

1. Zero-frame leaf + caller-saved home — with gap-1 promotion gust_mix needs no frame; as a leaf it can keep the live local in a t-reg (no save/restore) where conservative LLVM may not.
2. Mask elision via the verified range — the clamp proves v ∈ [1000,2000] (11 bits), so the second u16 narrow is provably dead and deletable — a fact LLVM doesn't carry (it only elides via the mechanical shift-pair match). This is the thesis lever.
3. Clamp-arm elision — if the pre-clamp range over the known input domain already satisfies a bound, drop that blt/bge arm. LLVM emits both unconditionally.

The one architectural recommendation

Build an RV32 post-lowering pass layer in synth-backend-riscv over Vec<RiscVOp> mirroring liveness — don't generalize the ARM passes (hard-typed; ARM-only outputs: IT-predication, uxth). Lift the reusable analysis primitive (RegEffect/reg_dead_by_redef, liveness.rs:25+) to a backend-agnostic core, then thin RV peepholes on top. RiscVOp (riscv_op.rs:68-193) is already clean rd/rs1/rs2 SSA-ish — a good substrate.

Priority (smallest blast radius first): (1) VstackVal::Const immediate-aware lowering — kills gaps 3+4's lis + enables andi; (2) leaf i32 local promotion → s-regs — kills the frame + spills; (3) cmp→branch fusion peephole; (4) proof-carrying mask/clamp-arm elision (the beat-LLVM lever). Each flag-gated, off-default → byte-identical, mirroring the ARM gate discipline — and I'll run each on the ESP32-C3 DWT bench (the on-silicon gate, same protocol as the M4 levers in #428).

This is the same measure→file→ship→re-measure loop the ARM backend just went through (64→48 cyc on real M4); RV32 is one full lever-set behind and the path to parity (then past LLVM) is the four items above.

[avrabe]

[issue-hunt loop] Triaged — tracked as the RISC-V lever-parity follow-up (epic #242).

Confirmed the gap: the cmp→select / local-promotion / imm-shift-fold levers live in arm_backend.rs only; synth-backend-riscv has none of the SYNTH_* flags, so RV32 dissolved code carries the spills/reg-shifts/materialized-bools the ARM levers eliminated (your 2.12× vs 1.66× on ESP32-C3 silicon matches that).

This is a real multi-lever porting effort (3 levers, each its own flag-off → ESP32-C3 gate → flip), so it's scoped as a tracked feature, not a single pass. Sequencing note: the ARM local-promotion lever just hit a register-exhaustion regression on dense functions (#474, fix in #475) — the RV32 port (s1-s11 promotion) should carry the same promotion-off exhaustion fallback from the start so it doesn't reintroduce that class. Likely order, cheapest-first: imm-shift-fold (slli/srli/srai) → cmp→select (slt/seqz branchless) → s-reg local promotion (+ the #474 fallback). Each gated on your ESP32-C3 mcycle/systimer harness, same protocol as the M4 runs.

Not this pass's deliverable (the #474 regression took priority); tracked for the next RISC-V increment.

— issue-hunt loop (avrabe automation), not a maintainer decision.

[avrabe]

Confirmed datum: RISC-V gets zero benefit from the v0.13–0.15 levers

Re-dissolved gale's gust_mix with synth 0.15.0 for both backends from the same stripped+loom-inlined wasm:

• ARM (cortex-m3): 132 B → 90 B, cycle ratio vs LLVM 2.63× → 1.81×
• RISC-V (-b riscv --target esp32c3): 164 B → 164 B, byte-identical to the 0.12.0 object

So while ARM closed most of the gap, RV32 is unchanged — the esp32c3 on-silicon ratio stays 2.12× (vs ARM's 1.66–1.81×). RISC-V is now the lagging architecture by a clear margin, which raises the priority of this port. The four levers to bring over, in the order they paid off on ARM: (1) cmp→select→branchless predication, (2) redundant stack-reload elimination, (3) i32 local promotion (with the reg-pressure cost-gate from #474), (4) immediate-shift folding. gale's esp32c3 object is therefore not re-pinned in pulseengine/gale#112 (no change to ship).

[avrabe]

[issue-hunt loop] Confirmed + prioritized — RISC-V port is the active lever. Thanks for the clean datum (ARM 132→90 B / 2.63×→1.81×; RV32 164→164 B byte-identical). RISC-V being the lagging arch by a clear margin is exactly the trigger to port.

This is now in flight as a feature loop. Lever 1 (uxth/uxtb mask fold) just landed flag-off for ARM (#480); the RISC-V port is sequenced after the remaining ARM levers, in your paid-off order: (1) cmp→select→branchless slt/seqz, (2) stack-reload elim, (3) i32 s-reg promotion with the #474 reg-pressure fallback baked in from the start (so RV32 never reintroduces the control_step exhaustion class), (4) immediate-shift folding (slli/srli/srai). Each will land flag-off → your esp32c3 mcycle/systimer gate → flip, same protocol as the ARM levers cleared here.

Will ping when the first RV32 lever is ready for an esp32c3 run.

— issue-hunt loop (avrabe automation), not a maintainer decision.