Summary
#23 reports the RMS_NORM dispatcher calling an AVX-512 kernel unconditionally and
faulting on Zen 3. That is not an isolated case — the same pattern appears in at
least three more places, each a SIGILL on any host without AVX-512 (Zen 1/2/3 and
older AMD parts included).
1. Native matmul epilogue helpers. scale_tile() is declared
target("avx512f") (fp32_gemm_looper.cpp) and apply_postops_tile()
target("avx512f,avx512bw,fma") (postop.cpp). Both are called with no ISA
guard — eight call sites in the FP32 looper alone. Reached by a non-unit alpha, or
any post-op the microkernel cannot fuse; the looper's own beta/alpha rescaling
makes the first routine.
Thread 2 "gtests" received signal SIGILL, Illegal instruction.
#0 native::scale_tile(float*, int, int, int, float)
=> vbroadcastss %xmm2,%zmm1
Note benchdnn does not catch this: it defaults to alpha=1 and fuses a lone relu
into the microkernel, so neither helper is reached. The gtests randomise alpha and
hit it on the first case.
2. Dynamic-quant reorder. The dispatch in
reorder_data_type/dynamic_quant_impl/dynamic_dispatch.cpp calls the _native
(AVX-512) kernels with no capability check:
Thread 4 "gtests" received signal SIGILL, Illegal instruction.
#0 reorder::dynamic_per_token_quant_bf16_s8_native(unsigned short const*, signed char*, float*, long, long)
=> vpternlogd $0xff,%zmm4,%zmm4,%zmm4
Reproduce: ./gtests --gtest_filter=*DynamicQuant* → exit 132.
For contrast, the static quant path in the same module is guarded correctly —
select_reorder_algo() refuses reorder_algo_t::native unless avx512f and
avx512bw/vl are present, and even documents the Xeon Phi case. Only the dynamic
path is missing that check.
3. LOWOHA embedding-bag. Two unguarded dispatches:
dispatch_kernel.hpp's dispatch_avx512_kernel runs AVX-512 kernels after the
FBGEMM attempt with no avx512f check, and embag_operator_impl.cpp selects the
_avx2 kernels without checking AVX2. The latter faults on Bulldozer/Piledriver/
Steamroller, which have FMA3 but no AVX2.
Suggested fixes
Each site needs the check the static-quant path already demonstrates. For the
matmul epilogue helpers a portable implementation is nearly free: every one of the
16 post-op cases already carries a scalar tail loop for the sub-16-element
remainder, so the portable path is those tails and agrees with the vector path by
construction. Verified equivalent by forcing the portable path on an AVX-512 host
and comparing against the reference kernel on identical inputs and seed.
Reference branches:
Environment
main @ 70f4dbf, --no-aocldlp, AMD PRO A10-8770E (Excavator). The embag AVX2
case additionally affects pre-Excavator family 15h parts.
Summary
#23 reports the RMS_NORM dispatcher calling an AVX-512 kernel unconditionally and
faulting on Zen 3. That is not an isolated case — the same pattern appears in at
least three more places, each a SIGILL on any host without AVX-512 (Zen 1/2/3 and
older AMD parts included).
1. Native matmul epilogue helpers.
scale_tile()is declaredtarget("avx512f")(fp32_gemm_looper.cpp) andapply_postops_tile()target("avx512f,avx512bw,fma")(postop.cpp). Both are called with no ISAguard — eight call sites in the FP32 looper alone. Reached by a non-unit alpha, or
any post-op the microkernel cannot fuse; the looper's own
beta/alpharescalingmakes the first routine.
Note benchdnn does not catch this: it defaults to alpha=1 and fuses a lone relu
into the microkernel, so neither helper is reached. The gtests randomise alpha and
hit it on the first case.
2. Dynamic-quant reorder. The dispatch in
reorder_data_type/dynamic_quant_impl/dynamic_dispatch.cppcalls the_native(AVX-512) kernels with no capability check:
Reproduce:
./gtests --gtest_filter=*DynamicQuant*→ exit 132.For contrast, the static quant path in the same module is guarded correctly —
select_reorder_algo()refusesreorder_algo_t::nativeunless avx512f andavx512bw/vl are present, and even documents the Xeon Phi case. Only the dynamic
path is missing that check.
3. LOWOHA embedding-bag. Two unguarded dispatches:
dispatch_kernel.hpp'sdispatch_avx512_kernelruns AVX-512 kernels after theFBGEMM attempt with no
avx512fcheck, andembag_operator_impl.cppselects the_avx2kernels without checking AVX2. The latter faults on Bulldozer/Piledriver/Steamroller, which have FMA3 but no AVX2.
Suggested fixes
Each site needs the check the static-quant path already demonstrates. For the
matmul epilogue helpers a portable implementation is nearly free: every one of the
16 post-op cases already carries a scalar tail loop for the sub-16-element
remainder, so the portable path is those tails and agrees with the vector path by
construction. Verified equivalent by forcing the portable path on an AVX-512 host
and comparing against the reference kernel on identical inputs and seed.
Reference branches:
Environment
main@70f4dbf,--no-aocldlp, AMD PRO A10-8770E (Excavator). The embag AVX2case additionally affects pre-Excavator family 15h parts.