Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#6,100 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
65/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c
Ambito
backend

Direzione di ricerca

Start in driver/level3/level3_syrk.c and syrk_kernel.c where GEMM_UNROLL_MN=8 drives panel packing and slicing, then compare against kernel/arm64/gemm_ncopy_sve_v2x8.c and gemm_tcopy_sve_v2x8.c to see the 2*svcntw() row grouping the wrapper never produces. Check param.h ARMV8SVE entries and kernel/setparam-ref.c where sgemm_unroll_mn is derived. Done means 0 failures across the 768-case sweep at VL128/256/512 without runtime dispatch mutation, while ARMV8 and A64FX sweeps still pass under QEMU.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
C
Stelle
7.6k
Fork
1.7k
Merge medio
1g 19h
PR unite (30g)
53

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenMathLib/OpenBLAS

Tutte le issue di OpenMathLib/OpenBLAS

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.