perf: LASX kernels on loong64 (sum, dot, sqrt, elementwise, 8x8 GEMM)

.github/workflows/ci.yml

@@ -15,8 +15,9 @@ permissions:
 # SIMD-dispatched package: each arch compiles exactly one sumSIMD wrapper — the
 # amd64 SSE2 wrapper (reduce_amd64.go -> sum_amd64.s), the arm64 NEON wrapper
 # (reduce_arm64.go -> sum_arm64.s), the ppc64le VSX wrapper (reduce_ppc64le.go
-# -> sum_ppc64le.s), or the scalar-alias wrapper (reduce_generic.go, on
-# loong64/riscv64/s390x and 32-bit). No single build sees
+# -> sum_ppc64le.s), the loong64 LASX wrapper (reduce_loong64.go ->
+# sum_loong64.s), or the scalar-alias wrapper (reduce_generic.go, on
+# riscv64/s390x and 32-bit). No single build sees
 # more than one, so no single run covers them all.
 #
 # The honest split:
@@ -37,9 +38,10 @@ permissions:
 #
 # So every line is either statement-covered by the gate or executed by a
 # per-arch job; the gate is never lowered and there is no coverage-gaming knob.
-# amd64/arm64/ppc64le ship SIMD kernels (ppc64le's run under qemu here and were
-# run on real POWER8/POWER9); loong64/riscv64/s390x keep the validated scalar
-# path for now.
+# amd64/arm64/ppc64le/loong64 ship SIMD kernels (ppc64le's and loong64's were
+# run on real POWER8/POWER9 and a Loongson 3C5000L; under qemu here loong64
+# takes its scalar fallback unless the emulated CPU reports LASX);
+# riscv64/s390x keep the validated scalar path for now.
 jobs:
   test:
     name: test (${{ matrix.os }})
@@ -124,12 +126,12 @@ jobs:
           go-version: stable
       - run: sudo apt-get update && sudo apt-get install -y qemu-user-static
       - name: Regenerate committed assembly and check it is current
-        if: matrix.goarch == 'ppc64le'
+        if: matrix.goarch == 'ppc64le' || matrix.goarch == 'loong64'
         run: |
-          ( cd internal/kernels/asmgen/ppc64le && go run . )
-          mv internal/kernels/asmgen/ppc64le/sum_ppc64le.s internal/kernels/sum_ppc64le.s
-          git diff --exit-code -- internal/kernels/sum_ppc64le.s || {
-            echo "::error::generated ppc64le assembly is stale; run go generate and commit"; exit 1; }
+          ( cd internal/kernels/asmgen/${{ matrix.goarch }} && go run . )
+          mv internal/kernels/asmgen/${{ matrix.goarch }}/sum_${{ matrix.goarch }}.s internal/kernels/sum_${{ matrix.goarch }}.s
+          git diff --exit-code -- internal/kernels/sum_${{ matrix.goarch }}.s || {
+            echo "::error::generated ${{ matrix.goarch }} assembly is stale; run go generate and commit"; exit 1; }
       - name: Vet + test under qemu (${{ matrix.goarch }})
         run: |
           GOOS=linux GOARCH=${{ matrix.goarch }} go vet ./...

README.md

@@ -59,14 +59,15 @@ methods (`AddInto`, `SqrtInto`, …) remain the way to reuse one named buffer.
 
 The numeric inner loops are kept behind a narrow kernel API. Behind it, large
 elementwise ops, reductions and products run **multicore** (across
-`GOMAXPROCS`). On **amd64, arm64 and ppc64le** the hot loops are
+`GOMAXPROCS`). On **amd64, arm64, ppc64le and loong64** the hot loops are
 [go-asmgen](https://github.com/go-asmgen)-generated SIMD kernels: sum,
 add/sub/mul/div, sqrt and the dot product (SSE2 or AVX2/FMA on amd64, NEON on
-arm64, VSX on ppc64le), max/min too on amd64, and a **panel-packed,
-cache-blocked GEMM** with an SIMD-FMA micro-kernel (NEON 4×8; AVX2/FMA 6×8
-chosen at run time, SSE2 fallback; VSX 8×8), the OpenBLAS/BLIS structure. The
-other 64-bit targets (riscv64, loong64, s390x) and the 32-bit ones run the
-same pure-Go code those kernels are tested against. `Exp` and `Log` are ports of Arm's optimized-routines
+arm64, VSX on ppc64le, LASX on loong64 when the CPU has it), max/min too on
+amd64, and a **panel-packed, cache-blocked GEMM** with an SIMD-FMA
+micro-kernel (NEON 4×8; AVX2/FMA 6×8 chosen at run time, SSE2 fallback; VSX
+8×8; LASX 8×8), the OpenBLAS/BLIS structure. The other 64-bit targets
+(riscv64, s390x) and the 32-bit ones run the same pure-Go code those kernels
+are tested against. `Exp` and `Log` are ports of Arm's optimized-routines
 (≤ 0.51 ULP measured, against up to 0.88 and 0.72 for Go's
 `math.Exp`/`math.Log` on arm64),
 and they are correct where amd64's `math.Exp` returns +Inf

docs/perf.md

@@ -603,6 +603,37 @@ so the serial GEMM is at 0.69×; 32 threads 13.1 ms at 1024², so MatMul is at
 0.56×. OpenBLAS unrolls further and uses POWER9-only `lxv` loads; Go's ppc64le
 baseline is POWER8.
 
+## loong64: LASX kernels (2026-10-04)
+
+Go's loong64 assembler has LASX vector float64 add/sub/mul/div, square root and
+256-bit loads, but no fused multiply-add and no broadcast load; go-asmgen
+v0.14.0 encodes `xvfmadd.d` and `xvldrepl.d` as `WORD`s (pinned against GNU as
+2.43, bit-identical to `math.FMA` on a Loongson 3C5000L; transitional until
+cmd/asm names them). go-ndarray uses them for sum, dot, sqrt, add/sub/mul/div
+and an 8×8 GEMM micro-kernel (16 four-lane accumulators, A broadcast by
+`xvldrepl.d`). LASX is not on every LoongArch CPU, so the kernels run only when
+the kernel reports it in AT_HWCAP (`/proc/self/auxv`), with the scalar code as
+the fallback; the parsing is a pure function tested on every target.
+
+Loongson 3C5000L (cfarm401, 32 cores), against the scalar code, best of 3
+interleaved runs (the host's load average of ~146 is processes stuck in
+uninterruptible sleep; its CPUs measured 100% idle):
+
+| op | before | after | gain |
+|----|--:|--:|:--:|
+| micro-kernel, 1 core | 7.0 GFLOP/s | 27.5 GFLOP/s | ×3.95 |
+| serial GEMM 512², 1 core | 5.3 GFLOP/s | 20.0 GFLOP/s | ×3.75 |
+| MatMul 64² / 512² / 1024², 32 threads | | | ×1.9 / ×1.3 / ×1.1 |
+| Sum 256 Ki / 4 Mi, 1 core | 658 / 11 750 µs | 65 / 4 615 µs | ×10.2 / ×2.5 |
+| Sum 1 Ki / 16 Ki (below the parallel threshold: one core) | | | ×16 / ×13 |
+| Sqrt 1 Ki–16 Ki | | | ×3.8 |
+| MatVec 1024² | 364 µs | 224 µs | ×1.6 |
+
+At 4 Mi elements in parallel, sum and sqrt are memory-bound (parity); the
+parallel 4 Mi sum is bimodal on this host (1.6 ms or 7 ms in either version),
+so only the minima are compared. No NumPy or BLAS is installable there (the
+host has no route to package mirrors), so there is no external reference.
+
 ## SIMD coverage
 
 - **amd64 (SSE2)** ships hand-vectorized `sum` (4-accumulator `ADDPD`), `sqrt`
@@ -629,7 +660,10 @@ baseline is POWER8.
 - **ppc64le (VSX)**, since v0.2.3: sum, dot, sqrt, add/sub/mul/div and an 8×8
   GEMM micro-kernel; max/min stay scalar (the ISA's `xvmaxdp` NaN rule is not
   NumPy's). See the ppc64le section above.
-- The other three 64-bit Go targets — **riscv64, loong64, s390x** — keep
+- **loong64 (LASX)**, since v0.2.5, when the kernel reports LASX in AT_HWCAP
+  (not every LoongArch CPU has it): sum, dot, sqrt, add/sub/mul/div and an 8×8
+  GEMM micro-kernel; max/min stay scalar. See the loong64 section above.
+- The other two 64-bit Go targets — **riscv64, s390x** — keep
   the validated scalar oracles, using the same four-accumulator max/min, direct
   sqrt loop, and a **scalar 4×4 GEMM micro-kernel** over the packed panels, and
   still get the **packing + cache blocking + multicore** structure (they have
@@ -638,10 +672,12 @@ baseline is POWER8.
   **ppc64le** has no vector-double arithmetic (no `XVADDDP`/`XVMADDADP`), which
   go-asmgen v0.13.0 now encodes as `WORD`s, so ppc64le has kernels;
   **loong64** has vector-double add/sub/mul/div (`VADDD` assembles to
-  `vfadd.d`, `VMULD` to `vfmul.d`, `XVADDD` to `xvfadd.d`) but no vector FMA;
+  `vfadd.d`, `VMULD` to `vfmul.d`, `XVADDD` to `xvfadd.d`) but no vector FMA
+  or broadcast load, which go-asmgen v0.14.0 encodes (transitionally), so
+  loong64 has kernels;
   **s390x** has them, FMA included (`VFADB`, `VFMADB`); **riscv64** has them
   (`VFADDVV`, `VFMACCVV`), but the V extension is optional and needs a run-time
-  check. So loong64, s390x and riscv64 kernels are work not yet done, not a
+  check. So s390x and riscv64 kernels are work not yet done, not a
   toolchain wall. (s390x additionally exercises the big-endian path in CI.)
 
 All six are exercised in CI (native amd64/arm64 + qemu for the rest); each

docs/plan-ndarray.md

@@ -123,7 +123,8 @@ suite (plus the per-arch CI jobs already wired in `.github/workflows/ci.yml`).
     lane-parallel grouping is a valid reordering — the same trade-off as
     NumPy's pairwise sum). Since v0.2.3 ppc64le has VSX kernels too (sum,
     dot, sqrt, elementwise, an 8×8 GEMM micro-kernel), through go-asmgen's
-    VSX encoders. The other targets (riscv64, loong64, s390x, 32-bit) keep the
+    VSX encoders, and since v0.2.5 loong64 has LASX kernels (used when the CPU
+    reports LASX). The other targets (riscv64, s390x, 32-bit) keep the
     validated scalar oracles plus a scalar 4×4 GEMM micro-kernel over the
     packed panels, with packing + cache-blocking + multicore; they have not
     been measured against NumPy. Split-CI: the pure-Go

internal/kernels/asmgen/go.mod

@@ -6,4 +6,4 @@ module github.com/go-ndarray/ndarray/internal/kernels/asmgen
 
 go 1.26.4
 
-require github.com/go-asmgen/asmgen v0.13.0
+require github.com/go-asmgen/asmgen v0.14.0

internal/kernels/asmgen/go.sum

@@ -1,2 +1,2 @@
-github.com/go-asmgen/asmgen v0.13.0 h1:O3DIZtgTgwHJ2uof6NhMCO1AnTZqub24r3DS83IjOb8=
-github.com/go-asmgen/asmgen v0.13.0/go.mod h1:Hj29fXioLRe9oSnQ18SuDBiOcCbu8Qwxba6/5TMr4+Y=
+github.com/go-asmgen/asmgen v0.14.0 h1:3f1L0X0RK1Vf1J9nb0Pei87vGRT5yhfNLNlecZ/SNFc=
+github.com/go-asmgen/asmgen v0.14.0/go.mod h1:Hj29fXioLRe9oSnQ18SuDBiOcCbu8Qwxba6/5TMr4+Y=

internal/kernels/asmgen/loong64/gen.go

@@ -0,0 +1,207 @@
+// Command gen produces sum_loong64.s, the LASX float64 kernels for loong64, via
+// go-asmgen. Run with: go run . (or `go generate` from the kernels package).
+//
+// Go's loong64 assembler has the LASX vector float64 add/sub/mul/div
+// (XVADDD, XVSUBD, XVMULD, XVDIVD), the square root (XVFSQRTD) and the
+// 256-bit loads and stores (XVMOVQ, with immediate offsets), but no fused
+// multiply-add and no broadcast load; those come from go-asmgen's encoders
+// (Builder.XVFMADDD, XVLDREPLD), which emit WORDs. LASX is not on every
+// LoongArch CPU, so the Go side calls these kernels only when the kernel
+// reports it (AT_HWCAP).
+//
+// Registers: R4.. hold the arguments; R12..R15 are scratch; X0..X31 are the
+// 256-bit LASX registers (four float64 lanes), F0..F31 their low lanes.
+package main
+
+import (
+	"fmt"
+	"os"
+
+	"github.com/go-asmgen/asmgen/emit"
+	"github.com/go-asmgen/asmgen/loong64"
+)
+
+const (
+	gemmMR = 8
+	gemmNR = 8
+)
+
+func main() {
+	f := emit.NewFile("loong64")
+	f.Add(sumKernel())
+	f.Add(dotKernel())
+	f.Add(sqrtKernel())
+	for _, k := range []struct{ name, vec, sca string }{
+		{"addLASX", "XVADDD", "ADDD"}, {"subLASX", "XVSUBD", "SUBD"},
+		{"mulLASX", "XVMULD", "MULD"}, {"divLASX", "XVDIVD", "DIVD"},
+	} {
+		f.Add(binKernel(k.name, k.vec, k.sca))
+	}
+	f.Add(gemmKernel())
+	if err := os.WriteFile("sum_loong64.s", []byte(f.String()), 0o644); err != nil {
+		fmt.Fprintln(os.Stderr, err)
+		os.Exit(1)
+	}
+	fmt.Println("wrote sum_loong64.s")
+}
+
+// fold adds X0..X3 into X0, then its four lanes into F0.
+func fold(b *loong64.Builder) {
+	b.Raw("XVADDD X1, X0, X0").Raw("XVADDD X3, X2, X2").Raw("XVADDD X2, X0, X0")
+	for l := 0; l < 4; l++ {
+		b.Raw("XVMOVQ X0.V[%d], R%d", l, 12+l)
+	}
+	b.Raw("MOVV R12, F0").Raw("MOVV R13, F1").Raw("MOVV R14, F2").Raw("MOVV R15, F3")
+	b.Raw("ADDD F1, F0").Raw("ADDD F3, F2").Raw("ADDD F2, F0")
+}
+
+func zero(b *loong64.Builder, n int) {
+	for r := 0; r < n; r++ {
+		b.Raw("XVXORV X%d, X%d, X%d", r, r, r)
+	}
+}
+
+// sumKernel builds sumLASX(a *float64, n int) float64: four LASX accumulators
+// (16 doubles per iteration), folded, plus a scalar tail. A regrouping of the
+// sum, held to a tolerance like the other targets' SIMD sums.
+func sumKernel() *emit.Function {
+	sig := loong64.Layout([]string{"a", "n"}, []loong64.Type{loong64.Ptr, loong64.Int64},
+		[]string{"ret"}, []loong64.Type{loong64.Float64})
+	b := loong64.NewFunc("sumLASX", sig, 0)
+	b.LoadArg("a", "R4").LoadArg("n", "R5")
+	zero(b, 4)
+	b.Label("sloop").Raw("MOVV $16, R12").Raw("BLT R5, R12, sfold")
+	for k := 0; k < 4; k++ {
+		b.Raw("XVMOVQ %d(R4), X%d", 32*k, 4+k)
+	}
+	for k := 0; k < 4; k++ {
+		b.Raw("XVADDD X%d, X%d, X%d", 4+k, k, k)
+	}
+	b.Raw("ADDV $128, R4").Raw("ADDV $-16, R5").Raw("JMP sloop")
+	b.Label("sfold")
+	fold(b)
+	b.Label("stail").Raw("BEQ R5, sdone").
+		Raw("MOVD 0(R4), F1").Raw("ADDD F1, F0").
+		Raw("ADDV $8, R4").Raw("ADDV $-1, R5").Raw("JMP stail")
+	b.Label("sdone").StoreRet("F0", "ret").Ret()
+	return b.Func()
+}
+
+// dotKernel builds dotLASX(a, b *float64, n int) float64: four fused
+// multiply-add accumulators (xvfmadd.d), folded, plus a fused scalar tail.
+func dotKernel() *emit.Function {
+	sig := loong64.Layout([]string{"a", "b", "n"}, []loong64.Type{loong64.Ptr, loong64.Ptr, loong64.Int64},
+		[]string{"ret"}, []loong64.Type{loong64.Float64})
+	b := loong64.NewFunc("dotLASX", sig, 0)
+	b.LoadArg("a", "R4").LoadArg("b", "R6").LoadArg("n", "R5")
+	zero(b, 4)
+	b.Label("dloop").Raw("MOVV $16, R12").Raw("BLT R5, R12, dfold")
+	for k := 0; k < 4; k++ {
+		b.Raw("XVMOVQ %d(R4), X%d", 32*k, 4+k)
+		b.Raw("XVMOVQ %d(R6), X%d", 32*k, 8+k)
+	}
+	for k := 0; k < 4; k++ {
+		b.XVFMADDD(k, 4+k, 8+k, k) // X(k) = a*b + X(k)
+	}
+	b.Raw("ADDV $128, R4").Raw("ADDV $128, R6").Raw("ADDV $-16, R5").Raw("JMP dloop")
+	b.Label("dfold")
+	fold(b)
+	b.Label("dtail").Raw("BEQ R5, ddone").
+		Raw("MOVD 0(R4), F1").Raw("MOVD 0(R6), F2").Raw("FMADDD F0, F2, F1, F0"). // F0 = F1*F2 + F0; Go's order is Fa, Fk, Fj, Fd
+		Raw("ADDV $8, R4").Raw("ADDV $8, R6").Raw("ADDV $-1, R5").Raw("JMP dtail")
+	b.Label("ddone").StoreRet("F0", "ret").Ret()
+	return b.Func()
+}
+
+// sqrtKernel builds sqrtLASX(dst, src *float64, n int): XVFSQRTD over 16
+// doubles per iteration, SQRTD for the tail. Both are the correctly rounded
+// IEEE square root, so the result is bit-identical to math.Sqrt.
+func sqrtKernel() *emit.Function {
+	sig := loong64.Layout([]string{"dst", "src", "n"}, []loong64.Type{loong64.Ptr, loong64.Ptr, loong64.Int64}, nil, nil)
+	b := loong64.NewFunc("sqrtLASX", sig, 0)
+	b.LoadArg("dst", "R4").LoadArg("src", "R6").LoadArg("n", "R5")
+	b.Label("qloop").Raw("MOVV $16, R12").Raw("BLT R5, R12, qtail")
+	for k := 0; k < 4; k++ {
+		b.Raw("XVMOVQ %d(R6), X%d", 32*k, k)
+	}
+	for k := 0; k < 4; k++ {
+		b.Raw("XVFSQRTD X%d, X%d", k, 4+k)
+	}
+	for k := 0; k < 4; k++ {
+		b.Raw("XVMOVQ X%d, %d(R4)", 4+k, 32*k)
+	}
+	b.Raw("ADDV $128, R4").Raw("ADDV $128, R6").Raw("ADDV $-16, R5").Raw("JMP qloop")
+	b.Label("qtail").Raw("BEQ R5, qdone").
+		Raw("MOVD 0(R6), F1").Raw("SQRTD F1, F1").Raw("MOVD F1, 0(R4)").
+		Raw("ADDV $8, R4").Raw("ADDV $8, R6").Raw("ADDV $-1, R5").Raw("JMP qtail")
+	b.Label("qdone").Ret()
+	return b.Func()
+}
+
+// binKernel builds name(dst, a, b *float64, n int): dst[i] = a[i] OP b[i], 16
+// doubles per iteration with the LASX op, a scalar tail with sca. Each lane is
+// one correctly rounded IEEE operation, bit-identical to the scalar oracle.
+func binKernel(name, vec, sca string) *emit.Function {
+	sig := loong64.Layout([]string{"dst", "a", "b", "n"},
+		[]loong64.Type{loong64.Ptr, loong64.Ptr, loong64.Ptr, loong64.Int64}, nil, nil)
+	b := loong64.NewFunc(name, sig, 0)
+	b.LoadArg("dst", "R4").LoadArg("a", "R6").LoadArg("b", "R7").LoadArg("n", "R5")
+	l := name[:3]
+	b.Label(l+"loop").Raw("MOVV $16, R12").Raw("BLT R5, R12, %stail", l)
+	for k := 0; k < 4; k++ {
+		b.Raw("XVMOVQ %d(R6), X%d", 32*k, k)
+		b.Raw("XVMOVQ %d(R7), X%d", 32*k, 4+k)
+	}
+	for k := 0; k < 4; k++ {
+		b.Raw("%s X%d, X%d, X%d", vec, 4+k, k, 8+k) // X(8+k) = X(k) OP X(4+k)
+	}
+	for k := 0; k < 4; k++ {
+		b.Raw("XVMOVQ X%d, %d(R4)", 8+k, 32*k)
+	}
+	b.Raw("ADDV $128, R4").Raw("ADDV $128, R6").Raw("ADDV $128, R7").Raw("ADDV $-16, R5").Raw("JMP %sloop", l)
+	b.Label(l+"tail").Raw("BEQ R5, %sdone", l).
+		Raw("MOVD 0(R6), F1").Raw("MOVD 0(R7), F2").Raw("%s F2, F1", sca).Raw("MOVD F1, 0(R4)").
+		Raw("ADDV $8, R4").Raw("ADDV $8, R6").Raw("ADDV $8, R7").Raw("ADDV $-1, R5").Raw("JMP %stail", l)
+	b.Label(l + "done").Ret()
+	return b.Func()
+}
+
+// gemmKernel builds gemmMicro8x8LASX(kc int, pa, pb, c *float64, ldc int):
+//
+//	for p in [0,kc):  C[r][col] += pa[p*8+r] * pb[p*8+col]   (r<8, col<8)
+//
+// 16 accumulators X0..X15 (row r in X(2r), X(2r+1), four columns each), the B
+// row in X16, X17, and each A value broadcast by xvldrepl.d into X18..X25,
+// then xvfmadd.d: 16 fused multiply-adds per k step against 10 loads. Fused,
+// like the other FMA kernels; on integer-valued data it equals the scalar
+// ikj oracle exactly.
+func gemmKernel() *emit.Function {
+	sig := loong64.Layout([]string{"kc", "pa", "pb", "c", "ldc"},
+		[]loong64.Type{loong64.Int64, loong64.Ptr, loong64.Ptr, loong64.Ptr, loong64.Int64}, nil, nil)
+	b := loong64.NewFunc("gemmMicro8x8LASX", sig, 0)
+	b.LoadArg("kc", "R5").LoadArg("pa", "R6").LoadArg("pb", "R7").LoadArg("c", "R8").LoadArg("ldc", "R9")
+	b.Raw("SLLV $3, R9") // ldc -> bytes
+	zero(b, 16)
+	b.Raw("BEQ R5, gstore")
+	b.Label("gloop")
+	b.Raw("XVMOVQ 0(R7), X16").Raw("XVMOVQ 32(R7), X17")
+	for r := 0; r < gemmMR; r++ {
+		b.XVLDREPLD(18+r, 6, 8*r)
+	}
+	for r := 0; r < gemmMR; r++ {
+		b.XVFMADDD(2*r, 18+r, 16, 2*r)
+		b.XVFMADDD(2*r+1, 18+r, 17, 2*r+1)
+	}
+	b.Raw("ADDV $%d, R6", 8*gemmMR).Raw("ADDV $%d, R7", 8*gemmNR).Raw("ADDV $-1, R5").Raw("BNE R5, gloop")
+	b.Label("gstore")
+	for r := 0; r < gemmMR; r++ {
+		b.Raw("XVMOVQ 0(R8), X16").Raw("XVMOVQ 32(R8), X17")
+		b.Raw("XVADDD X%d, X16, X16", 2*r).Raw("XVADDD X%d, X17, X17", 2*r+1)
+		b.Raw("XVMOVQ X16, 0(R8)").Raw("XVMOVQ X17, 32(R8)")
+		if r < gemmMR-1 {
+			b.Raw("ADDV R9, R8")
+		}
+	}
+	b.Ret()
+	return b.Func()
+}

internal/kernels/gemm_generic.go

@@ -1,11 +1,11 @@
-//go:build !arm64 && !amd64 && !ppc64le
+//go:build !arm64 && !amd64 && !ppc64le && !loong64
 
 package kernels
 
 // Generic GEMM micro-kernel for the targets without a vector-double SIMD kernel
-// (loong64, riscv64, s390x and the 32-bit ones): a portable scalar 4x4 register
+// (riscv64, s390x and the 32-bit ones): a portable scalar 4x4 register
 // tile over the packed panels. There is no hand-vectorized .s here yet (Go's
-// assembler has vector-double arithmetic for loong64, s390x and riscv64, see
+// assembler has vector-double arithmetic for s390x and riscv64, see
 // docs/perf.md) — but the kernel still gets the two structural wins of the packed
 // GEMM: the panels are contiguous unit-stride (so the loads are conflict-free,
 // the L1-collision fix), and the cache-blocking loop nest plus the multicore