simd(s390x): vector-facility kernels; native-endian AT_HWCAP

[tannevaled]

What

• s390x kernels, generated by go-asmgen (asmgen/s390x/gen.go → sum_s390x.s), for sum, dot (VFMADB), sqrt (VFSQDB) and add/sub/mul/div (VFADB/VFSDB/VFMDB/VFDDB). Each loop takes eight float64 in four two-lane registers (VLM/VSTM), then a scalar tail. No WORDs.
• Gating: on HWCAP_S390_VXRS (bit 11). Every z13+ has the facility, but a kernel can disable it.
• Still scalar: max/min and the GEMM micro-kernel. The vector max with NumPy's NaN rule (VFMAXDB, Java mode) needs the z14, beyond the z13 that Go supports.
• Operand order measured, not read. Each instruction was run once on known inputs under emulation. VFSDB V1, V2, V3 gives V3 = V2 − V1; VFDDB follows the same pattern; VFMADB V1, V2, V3, V4 gives V4 = V1·V2 + V3; FSUB F1, F0 gives F0 = F0 − F1.
• Bug fixed on the way. hwcapFrom parsed /proc/self/auxv as little-endian, which is wrong on big-endian s390x. It now uses binary.NativeEndian, and its test builds auxv in native order too. Under emulation, useVX comes out true as it should.
• Build tags: reduce_generic.go / dot_generic.go now cover only the 32-bit targets. The fence and guard tests include s390x. The s390x qemu lane regenerates and checks sum_s390x.s.

Validation — ⚠ emulation only

No s390x host was reachable (the LinuxONE timed out), so nothing here is a performance claim. Docs, README and SECURITY.md all say so.

• Under Docker's qemu-s390x: the full kernels and root suites pass, including the fence tests, TestBinSIMD (bit-identical incl. edge values), TestSumSIMD and Dot. TestVXDetected reports useVX = true.
• Sabotages, both caught under emulation: swapped subtraction operands (sub n=8 [0]: simd=-1286.9…, scalar=1286.9…), and a dot that does not advance b (Dot1DP … != …).
• Coverage stays at 100% (amd64/arm64 gate). go vet passes on 8 architectures, and go test -c builds on every dist pair.

Version: v0.8.0: kernels on the last 64-bit target, plus the AT_HWCAP byte-order fix.

🤖 Generated with Claude Code