x86/clmul: use VEX-encoded 256-bit VPCLMULQDQ on CPUs without AVX-512#1417
Draft
fo40225 wants to merge 1 commit into
Draft
x86/clmul: use VEX-encoded 256-bit VPCLMULQDQ on CPUs without AVX-512#1417fo40225 wants to merge 1 commit into
fo40225 wants to merge 1 commit into
Conversation
The Intel Intrinsics Guide lists VPCLMULQDQ + AVX512VL for _mm256_clmulepi64_epi128, but that only describes the EVEX-encoded form. The instruction also has a VEX.256 encoding which merely requires VPCLMULQDQ + AVX, and compilers emit it when AVX-512 is not enabled (GCC since 9.1 / PR target/88541, Clang since 10). Requiring AVX512VL_NATIVE forced CPUs with VPCLMULQDQ but no AVX-512 -- notably AMD Zen 3 -- onto the slow portable fallback. Follow the pattern already used in gfni.h: use the native intrinsic when AVX512VL is available, or when AVX is available without AVX512F (the latter condition avoids compilers encoding the 256-bit form as EVEX, which would require AVX512VL). The 512-bit intrinsic is unchanged; ZMM has no VEX encoding. Also fix the native alias guards to use OR instead of AND: an alias must be defined whenever any required feature is missing, otherwise a target with exactly one of the two features gets neither the native definition nor the SIMDe alias and fails to compile under SIMDE_ENABLE_NATIVE_ALIASES.
fo40225
marked this pull request as draft
July 19, 2026 02:47
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
simde_mm256_clmulepi64_epi128requires bothSIMDE_X86_VPCLMULQDQ_NATIVEandSIMDE_X86_AVX512VL_NATIVEto use the native intrinsic.CPUs that support VPCLMULQDQ but lack AVX-512 notably AMD Zen 3 (Ryzen 5000 / EPYC 7003) fall back to the portable carry-less multiply emulation, which is orders of magnitude slower than the single hardware instruction.
Root cause
The guard follows the Intel Intrinsics Guide, which lists AVX512VL as a CPUID requirement but the Guide only documents the EVEX-encoded form.
Per the Intel SDM and AMD APM the instruction has two encodings:
The C intrinsic is not tied to an encoding: GCC ≥ 9.1 (PR target/88541) and Clang ≥ 10 emit the VEX form when compiling with
-mvpclmulqdq -mavxand no AVX-512.Changes
VPCLMULQDQ && (AVX512VL || (AVX && !AVX512F)).The
!AVX512Fexclusion avoids configurations where a compiler could pick the EVEX encoding without AVX512VL being available.&&→||.An alias must be defined whenever any required feature is missing; with
&&, a target having exactly one of the two features got neither the native definition nor the SIMDe alias, breakingSIMDE_ENABLE_NATIVE_ALIASESbuilds.This matches the existing convention elsewhere (e.g. sse2.h, gfni.h).
Verification
With GCC 13,
simde_mm256_clmulepi64_epi128now compiles to a singlevpclmulqdqunder-march=znver3and-mvpclmulqdq -mavx(previously: portable fallback), still uses the native intrinsic under-mvpclmulqdq -mavx512vl, and correctly falls back with-mvpclmulqdq -mavx512f(no VL) and with plain-mpclmul -mavx2.GFNI already handles this correctly, and SIMDe has no 256/512-bit VAES implementations, so this was the only remaining intrinsic affected by the VEX/EVEX distinction.