Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#6,100 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
65/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
c
Bereich
backend

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
C
Sterne
7.6k
Forks
1.7k
Ø Merge
1 T. 11 Std.
Gemergte PRs (30 T.)
55

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus OpenMathLib/OpenBLAS

Alle Issues in OpenMathLib/OpenBLAS

Ähnliche Issues

Weitere Issues zu C

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.