Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#6,100 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
65/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
c
Domínio
backend

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
C
Estrelas
7.6k
Forks
1.7k
Merge médio
1d 11h
PRs com merge (30d)
55

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de OpenMathLib/OpenBLAS

Todas as issues de OpenMathLib/OpenBLAS

Issues semelhantes

Mais issues de C

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.