Skip to content

ARMV8SVE SYRK/SYR2K panel splits disagree with SVE packing at wider VL #6100

Open

Description

@BenKnill

ARMV8SVE SYRK/SYR2K panel splits disagree with SVE packing at wider VL

On develop 31e82fa8c509e6f0d96288de3c20d8916d894e72, built with GCC 15.2 and
DYNAMIC_ARCH=1, cblas_ssyrk(RowMajor, Upper, NoTrans, 40, 8, 1, A, 8, 1, C, 40)
returns wrong results with OPENBLAS_CORETYPE=ARMV8SVE at SVE vector lengths
256 and 512 bits. QEMU 8.2.2 and 10.2.1 give the same original-census output:

SVE vector length Original census, upper triangle 768-case SYRK/SYR2K sweep Same sweep after diagnostic split change
128 bits Correct 0 failures 0 failures; split 8 → 8
256 bits 528 wrong entries 344 failures 0 failures; split 8 → 16
512 bits 638 wrong entries 392 failures 0 failures; split 8 → 32

The sweep uses bounded dyadic inputs, so its scalar reference and the expected
single-precision results are exact. It checks row-major SSYRK and SSYR2K,
upper/lower triangles, NoTrans/Trans, tight/padded leading dimensions, 16 sizes
from 1 to 65, and k in {1,8,17}. It also checks output padding and the
untouched triangle. Alpha and beta are both 1. ARMV8 passes all 768 cases at
each tested length; A64FX passes all 768 at 512 bits.

Suspected cause

The SYRK driver
packs A in panels limited by GEMM_UNROLL_MN, and the
SYRK kernel wrapper
splits and slices packed A using that value. For ARMV8SVE the value is 8:
the target parameters
specify M=4 and N=8, and
the dispatch table
uses their maximum when no explicit MN override exists.

However, ARMV8SVE selects the interleaved SVE GEMM kernel and its v2 copy routines.
Their full A panels contain 2*svcntw() rows: 16 at VL256 and 32 at VL512.
Concatenating separately packed eight-row panels does not give the same layout.
The grouping is visible in
ncopy
and tcopy.

The diagnostic tuning.c changes only the dispatch table's
sgemm_unroll_mn from 8 to 2*svcntw(). The SVE library code and emulator
remain the same, and the failures disappear as shown above.
A64FX already sets SGEMM_DEFAULT_UNROLL_MN=32.
This supports a driver/packed-layout mismatch. The table mutation is a
diagnostic, not a proposed complete fix for every supported vector length,
routine, or thread configuration.

Reproduce

The attached openblas-sme-repro.zip contains witness.c,
tuning.c, the unchanged original census renamed census-witness.c, and
the relevant saved output. Extract it and run the following from its root
using Bash on Linux. Dependencies are Git, GNU Make, host GCC, an AArch64 GCC
15.2 cross toolchain with its glibc sysroot, and QEMU user mode (10.2.1 used
for the sweep; 8.2.2 also checked for the original census).

set -euo pipefail
git init openblas-src
git -C openblas-src fetch --depth=1 https://github.com/OpenMathLib/OpenBLAS.git 31e82fa8c509e6f0d96288de3c20d8916d894e72
git -C openblas-src checkout --detach FETCH_HEAD
cd openblas-src
sve_make_args=(ARCH=arm64 BINARY=64 TARGET=ARMV8 DYNAMIC_ARCH=1
  'DYNAMIC_LIST=ARMV9SME ARMV8SVE A64FX' NOFORTRAN=1 NO_LAPACK=1
  USE_THREAD=0 NUM_THREADS=1 HOSTCC=gcc CC=aarch64-linux-gnu-gcc
  AR=aarch64-linux-gnu-ar RANLIB=aarch64-linux-gnu-ranlib)
make -j4 "${sve_make_args[@]}"
make "${sve_make_args[@]}" PREFIX="$PWD/install" install
aarch64-linux-gnu-gcc -O2 -Wall -Wextra -Iinstall/include ../witness.c install/lib/libopenblas.a -lm -lpthread -o sve-witness
aarch64-linux-gnu-gcc -O2 -Wall -Wextra -Iinstall/include ../census-witness.c install/lib/libopenblas.a -lm -lpthread -o census-witness
aarch64-linux-gnu-gcc -O2 -Wall -Wextra -I. -DDYNAMIC_ARCH -DSMALL_MATRIX_OPT -DBUILD_BFLOAT16 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 ../tuning.c install/lib/libopenblas.a -lm -lpthread -o sve-tuning

sve_qemu=qemu-aarch64
sve_sysroot=/usr/aarch64-linux-gnu
for sve_bits in 128 256 512; do
  for sve_program in sve-witness sve-tuning; do
    env OPENBLAS_CORETYPE=ARMV8SVE OPENBLAS_NUM_THREADS=1 SME_TEST_VL="$sve_bits" \
      "$sve_qemu" -L "$sve_sysroot" -cpu "max,sve-max-vq=$((sve_bits/128))" "./$sve_program" sweep
  done
  env OPENBLAS_CORETYPE=ARMV8SVE OPENBLAS_NUM_THREADS=1 \
    "$sve_qemu" -L "$sve_sysroot" -cpu "max,sve-max-vq=$((sve_bits/128))" ./census-witness syrk_tiles
  env OPENBLAS_CORETYPE=ARMV8 OPENBLAS_NUM_THREADS=1 SME_TEST_VL="$sve_bits" \
    "$sve_qemu" -L "$sve_sysroot" -cpu "max,sve-max-vq=$((sve_bits/128))" ./sve-witness sweep
done
env OPENBLAS_CORETYPE=A64FX OPENBLAS_NUM_THREADS=1 SME_TEST_VL=512 \
  "$sve_qemu" -L "$sve_sysroot" -cpu max,sve-max-vq=4 ./sve-witness sweep

The witnesses report numerical failures in their output and return zero on
normal completion; read the final SWEEP: ... cases=768 failures=... or census
row. A crash, missing summary, or wrong reported core/vector length is not a
valid numerical result. For the QEMU 8.2.2 census comparison, set sve_qemu
to that executable and repeat the three census-witness syrk_tiles calls.

Native wide-SVE confirmation is unavailable. The reachable Apple M5 Linux
guest reports HWCAP_SVE=0; its SME support does not provide a native SVE
test. The source inspection and controlled split-size experiment support an
OpenBLAS defect, while the numerical reproductions reported here are under
QEMU.

First surfaced by differential testing during an arm64 SRU survey. Follow-up
investigation and local checks were prepared with Codex.

openblas-sme-repro.zip

Activity

  1. martin-frbg commented on Oct 14, 2026

    @martin-frbg
    Collaborator

    This is sort-of expected, as ARMV8SVE at least historically is a 128-bit SVE implementation, though this is only noted as a comment in param.h. For VL=256, one should use the NEOVERSEV1 target, and A64FX for VL=512. The dynamic_arm64 dispatch should probably utilize the same inline assembly call to determine VL for any unknown SVE-capable target and pick the best match instead of delegating everything to ARMV8SVE target, now that the new ARMV8SVE kernels are in place @almayne ?

  2. almayne commented on Oct 15, 2026

    @almayne
    Contributor

    If the issue is entirely down to the new interleaving kernels, I think it would be better to roll back to eg
    SGEMMKERNEL = sgemm_kernel_sve_v2x$(SGEMM_UNROLL_N).S
    for VL != 128, keeping
    SGEMMKERNEL = sgemm_kernel_inter_sve_v2x$(SGEMM_UNROLL_N).S
    for VL=128 only. But given this brought us very small perf improvements for only V1, and no improvement to V2, I would suggest we ditch the interleaving change. The value of my PR that got merged primarily was in the disentangling.

    Also, note that KERNEL.NEOVERSEV1 includes KERNEL.ARMV8SVE:

    include $(KERNELDIR)/KERNEL.ARMV8SVE

    Update: having seen your PR and response to my comment there you can ignore the above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions