Open sayantn opened 2 weeks ago
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:
@rustbot concern reason-for-concern
<description of the concern>
Concerns can be lifted with:
@rustbot resolve reason-for-concern
See documentation at https://forge.rust-lang.org
cc @rust-lang/compiler @rust-lang/compiler-contributors
Proposal
Intel has introduced the new
AVX10.N-256
instruction set, which enables use of only the 256-bit instructions of theavx512
set. LLVM uses theevex512
feature flag to differentiate betweenavx512
-avx10.N-512
andavx10.N-256
. Due to rust-lang/rust#121088, theavx512
target features auto-enableevex512
, making it impossible for Rust to useavx10.N-256
. A solution will be toevex512
target feature to Rustcevex512
target feature to all 512-bit intrinsics in stdarchAfter this change,
avx512
oravx10.N-512
instructions, it will enableavx512f
(and its friends) andevex512
avx10.N-256
instructions, it will enableavx512f
(and its friends) only(Known) Problems associated with this approach
As a large part of the Rust ecosystem already uses avx512 (even though it is unstable), this would have a large impact - all of those crates will have to also check for
evex512
This would create a disparity between cpu features and rust target features
The run-time detection for avx512 in std_detect has been stabilized, and we would need to change the semantics of avx512 feature detection - although this isn't much of a problem as there are no cpus with avx10 yet.
For reference, the Zulip thread is AVX10 target feature (re) organization
Alternatives
avx256f
target-features, which LLVM interprets as onlyavx512f
and the current semantic ofavx512f
can be preserved (See in Zulip). The possible counter-arguments will be too many target features (AVX512 already has 14, this would mean 14 more)Mentors or Reviewers
If you have a reviewer or mentor in mind for this work, mention them here. You can put your own name here if you are planning to mentor the work.
Process
The main points of the Major Change Process are as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.