Pick matching SVE fallback kernel in ARM64 DYNAMIC_ARCH by vector length

[martin-frbg]

for #6102 and related issues

[almayne]

Note that KERNEL.NEOVERSEV1 includes KERNEL.ARMV8SVE

[martin-frbg]

It does, but V1 has the GEMM_UNROLL_MN set appropriately, which should take care of the L3 packing issues

[BenKnill]

One units mismatch in the Linux fallback at df61124a: PR_SVE_GET_VL & PR_SVE_VL_LEN_MASK gives bytes, while cntw and the switch use 32-bit-word counts. Thus 128-bit and 256-bit VLs currently select the A64FX entry when this fallback is reached. The successful-query line should be:

if (veclen > -1) veclen = (veclen & PR_SVE_VL_LEN_MASK) / 4;

I checked the extracted branch with mocked 16/32/64-byte responses; the conversion restores the intended selections. This is a dispatch check, not a native numerical test. Linux ABI reference.

[martin-frbg]

One units mismatch in the Linux fallback at df61124a: PR_SVE_GET_VL & PR_SVE_VL_LEN_MASK gives bytes, while cntw and the switch use 32-bit-word counts. Thus 128-bit and 256-bit VLs currently select the A64FX entry when this fallback is reached. The successful-query line should be:

Thanks - I was just trying things on the side without local testing. Will update the PR accordingly...

[BenKnill]

Thanks — tested 8d91f949 in QEMU 10.2.1 with SME off and OPENBLAS_CORETYPE unset. At VL384, automatic dispatch selects A64FX and SSYRK (RowMajor/Upper/NoTrans, n=40, k=8, alpha=beta=1) gives 1.421875 at C[0,24] instead of the exact 1.21875.

Attached is a small default-case patch: retain A64FX at VL512 and use ARMV8 for unmatched lengths. With it, a 768-call SSYRK/SSYR2K sweep and both reduced #6102 DOT checks pass at VL128/256/384/512/640/1024/2048. The three explicit SVE selections are unchanged and also pass those checks before the patch. Patch, reproducer, commands, and logs attached. QEMU only; native hardware was not tested.

pr6130-closeout.zip

[martin-frbg]

Ahh, I misread your SSYRK issue and somehow hoped A64FX would work for the 384 case too. Dropping down to pure NEON kernels will probably not be much of a practical issue as long as there is no actual hardware with such VLs.
(Of course it would be nice if all SVE kernels were VL-agnostic, but choosing the best match among what we have doesn't feel like a bad compromise)