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

Steps / History

• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• _mm512_reduce_add_ps and friends are setting fast-math flags they should not set stdarch#1533

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.

[tarcieri]

Not sure if this is a good place to ask, but I'm curious if there are any blockers for stabilizing avx512_target_feature, or it just needs a stabilization PR.

I previously asked here without a reply: #44839 (comment)

[Amanieu]

Not sure if this is a good place to ask, but I'm curious if there are any blockers for stabilizing avx512_target_feature, or it just needs a stabilization PR.

Yes, this is the right place to ask: essentially this is blocked on the AVX512 baseline intrinsics still being incomplete, see my comment above.

[IceTDrinker]

what is considered baseline ?

I see that e.g. _mm512_cvtt_roundpd_epi64 from AVX512DQ is not available today and I don't see an axv512dq.md file in the core arch dir

[Amanieu]

I would consider F + VL/DQ/BW as the baseline for initial stabilization of AVX512 intrinsics. The MD files may be somewhat out of date and need someone to double-check against the full list of intrinsics.

[RalfJung]

We should resolve rust-lang/stdarch#1533 before stabilizing these intrinsics.

[nikic]

We also need to consider how this interacts with AVX10 now. In #121088 I made all the +avx512 target features imply +evex512 to restore the status quo, but this means that there is currently no way to support AVX10.N/256. We'll presumably want to figure out some way to support that before avx512 support is stabilized. Possibly by explicitly adding +evex512 to all avx512 intrinsics that use 512-vectors (and having the same requirement for user code).

[AlexanderSchuetz97]

A dumb question, since this appears to be blocked on some cpu instructions not having a corresponding wrapper function due to downstream compilers not supporting them yet, why not stabilize it peacemeal? The instructions that are already implemented (provided that they do work as advertised) would already help me out a lot. I dont really see the need why all avx512 instruction wrappers need to be stabilized at the same time.