Tracking Issue for AVX512 intrinsics

[Amanieu]

Feature gate: #![feature(stdarch_x86_avx512)]

This is a tracking issue for the AVX-512 (and related extensions) intrinsics in core::arch.

Public API

This feature covers all of the intrinsics from the following features:

• avx512bf16
• avx512bitalg
• avx512bw
• avx512cd
• avx512f
• avx512ifma
• avx512vbmi
• avx512vbmi2
• avx512vnni
• avx512vpopcntdq
• gfni
• vaes
• vpclmulqdq

VEX variants

• avxifma
• avxneconvert
• avxvnni
• avxvnniint16
• avxvnniint8

Implementation History

• Split the stdsimd feature into separate features stdarch#1486
• Implicitly enable evex512 if avx512 is enabled #121088
• Stop using the avx512er and avx512pf x86 target features #125498
• Expand avx512_target_feature to include VEX variants #126617

Steps

• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions and Other Concerns

• _mm512_reduce_add_ps and friends are setting fast-math flags they should not set stdarch#1533
• How will we handle AVX10?
• _mm512_shrdv_* intrinsics have incorrect argument order #130365
• We need i1xN support to call LLVM intrinsics for avx512vp2intersect.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[Jules-Bertholet]

@rustbot label O-x86

[IceTDrinker]

Hello, what are the guidelines to potentially contribute intrinsics?

Cheers

[Amanieu]

Currently the main blocker for stabilizing AVX-512 intrinsics is that we are still missing some. See these files for the list of missing intrinsics:

• https://github.com/rust-lang/stdarch/blob/master/crates/core_arch/avx512f.md
• https://github.com/rust-lang/stdarch/blob/master/crates/core_arch/avx512bw.md

There may also be missing intrinsics for some of the other AVX512 subsets, this should be double-checked.

[tgross35]

It seems like most of the intrinsics that are not yet implemented are labeled not in LLVM. Is stabilization blocked on those, or just the ones labeled need i1?

[Amanieu]

The documents were made quite a few years ago, and should be checked against the equivalent intrinsics in the latest version of Clang.

Regarding the "not in llvm", we can skip these since they are supported by neither Clang nor GCC. It seems these are only supported by icc for Xeon Phi targets.