[tannevaled]

AddBlocks8F32, the inner block of NumPy's pairwise sum, gains two kernels. Each runs behind the feature bit its float64 kernels already use (useRVV, useLASX), and the scalar loop runs otherwise. Both are spelled by Go's own assembler.

• riscv64: VSETIVLI $8, E32, M2 gives vl = 8 on every VLEN ≥ 128, the V extension's minimum. The eight accumulators sit in the group V2–V3, with one VFADDVV per block.
• loong64: the eight accumulators sit in two 128-bit LSX registers, with one VADDF (vfadd.s) per register per block.

There is one IEEE float32 addition per lane per block, in order, so float32 sums are unchanged bit for bit.

Run on the real hardware:

• The kernel tests (bit-identity, refusals, PROT_NONE fence) and the float32 sum tests pass on cfarm95 (SpacemiT X60, RVV, VLEN 256) and cfarm401 (Loongson 3C5000L).
• A sabotaged kernel fails the bit-identity test on both. That proves the kernel path, not the fallback, is the one taken there.
• All seven targets build.

Measured with old and new binaries alternating 6 times, one pinned thread, benchstat p = 0.002:

float32 Sum, 2¹⁴ / 2²⁰	change	controls
X60 (RVV)	−30% / −41%	float64, int32 ~
3C5000L (LSX)	−24% / −24%	float64, int32 ~

A first loong64 version lost, and was dropped. One 256-bit LASX register for all eight accumulators came out 26–47% slower than the scalar loop on the 3C5000L, with the host 0% busy. Every block's addition waited on the previous one: a single dependency chain, where the scalar loop has eight. Two LSX registers give two chains, as SSE2 does on amd64, and that version wins.

Left: ppc64le and s390x. Go's assembler lacks xvaddsp and vfasb; go-asmgen/asmgen#27 is the start.

🤖 Generated with Claude Code