Add evex512 target feature for AVX10

[sayantn]

Proposal

Intel has introduced the new AVX10.N-256 instruction set, which enables use of only the 256-bit instructions of the avx512 set. LLVM uses the evex512 feature flag to differentiate between avx512-avx10.N-512 and avx10.N-256. Due to rust-lang/rust#121088, the avx512 target features auto-enable evex512, making it impossible for Rust to use avx10.N-256. A solution will be to

• Add the evex512 target feature to Rustc
• Add the evex512 target feature to all 512-bit intrinsics in stdarch
• Revert Implicitly enable evex512 if avx512 is enabled rust#121088 and update the stdarch submodule

After this change,

• If CPU supports avx512 or avx10.N-512 instructions, it will enable avx512f (and its friends) and evex512
• If CPU supports avx10.N-256 instructions, it will enable avx512f (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

• As suggested by @Amanieu, we can add avx256f target-features, which LLVM interprets as only avx512f and the current semantic of avx512f 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:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

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.

[rustbot]

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

[apiraino]

@rfcbot concern design-around-naming-scheme

The discussion on Zulip seems to point to needing a wider and shared scheme for AVX targets. Possibly a compiler team design meeting after the MCP author drafts a document in RFC format.