perf(ch32v): V303/V307 build soft-float despite QingKe V4F FPU - evaluate rv32imafc/ilp32f

[zackees]

Severity: MEDIUM (performance, not correctness) — CH32V303/V307 are QingKe V4F cores with an FPU, but fbuild builds them soft-float (rv32imacxw/ilp32). Float-heavy sketches run several times slower than necessary.

Problem

genericCH32V303VCT6.json:13-14 and genericCH32V307VCT6.json:13-14 declare march: rv32imacxw, mabi: ilp32. The vendor boards.txt at the pinned core commit uses rv32imafcxw / ilp32f for CH32V30x. No FPU instructions are ever emitted; float math goes through libgcc soft-float calls.

Understating the ISA is safe (no faults) — this is purely a performance/parity question.

Parity note

Community-PIO-CH32V also uses rv32imacxw/ilp32 — so fbuild currently has A/B parity with PlatformIO and diverges from Arduino-IDE/vendor builds. Flipping this is a deliberate divergence; record it.

Prerequisites

1. The riscv -isystem multilib fix must land first, including its heuristic fix: real F-extension multilib dirs keep _zicsr (e.g. rv32imafc_zicsr/ilp32f), which the current march.split('_').next() logic mangles.
2. Verify the pinned xPack GCC 14.2.0-3 multilib set includes rv32imafc/ilp32f (riscv-none-elf-gcc -print-multi-lib).
3. Confirm the pinned core's D8/D8C startup needs no explicit FPU-enable beyond what it already does (mstatus.FS), and that normalize_march yields rv32imafc_zicsr from rv32imafcxw (it should — the xw-strip + zicsr-append path).

Fix

march: rv32imafcxw, mabi: ilp32f in the two V30x JSONs once prerequisites hold. Bench-verify a float-heavy sketch (e.g. FastLED HSV math) before/after.

Acceptance

• V303/V307 compile lines show -march=rv32imafc_zicsr -mabi=ilp32f; firmware links against the ilp32f multilib; nm shows no __addsf3-style soft-float libcalls for a float sketch.

From the 2026-07-21 CH32V bench-readiness sweep.

[zackees]

Parent meta: #1130 (2026-07-21 CH32V bench-readiness sweep).