Skip to content

Prefer avx512vl_256 over avxvnni for 256-bit sized batches#1381

Open
DiamonDinoia wants to merge 1 commit into
xtensor-stack:masterfrom
DiamonDinoia:prefer-avx512vl256-over-avxvnni
Open

Prefer avx512vl_256 over avxvnni for 256-bit sized batches#1381
DiamonDinoia wants to merge 1 commit into
xtensor-stack:masterfrom
DiamonDinoia:prefer-avx512vl256-over-avxvnni

Conversation

@DiamonDinoia

Copy link
Copy Markdown
Contributor

Reordering avx512vl_256 ahead of avxvnni makes 256-bit sized batches select it whenever AVX512VL is present.

When both AVX-VNNI and AVX512VL are available, make_sized_batch/sized_batch
walks all_x86_architectures in order and picks the first arch matching the
requested lane count. For 256-bit float/double batches this selected avxvnni,
whose masked load/store lower to vmaskmov{ps,pd} — a ~3-uop op on Intel that
also does not store-forward. avx512vl_256 (which inherits fma3<avx2>, so every
non-masked op is byte-identical) instead lowers masked load/store to EVEX
k-register moves (vmovups{k}, _mm256_mask*), 1 uop and forwardable.

Reordering avx512vl_256 ahead of avxvnni makes 256-bit sized batches select it
whenever AVX512VL is present. VNNI-only targets (e.g. Alder Lake client) still
resolve to avxvnni, since avx512vl_256 is filtered out of supported_architectures
there — so no target loses codegen, and AVX-512 targets gain clean k-masking.

Note: avx512vl_256 uses EVEX-encoded 256-bit ops, which do not trigger the
512-bit license-based downclock on Skylake-SP/Ice Lake/Sapphire Rapids.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant