Remove multi-field repr(simd)

[scottmcm]

Proposal

Originally, repr(simd) supported only multi-field form:

#[repr(simd)]
pub struct u8x32(u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8);

https://github.com/rust-lang/stdarch/blob/5f5ddf8f9a404d1f12b531095b13bccce97357ea/crates/core_arch/src/x86/mod.rs#L324-L329

But with const generics showing up (and because counting fields like that isn't the most fun thing in the world), an array-based version was added:

#[repr(simd)]
pub struct u8x32([u8; 32]);

Unsurprisingly, portable-simd uses that form:

https://github.com/rust-lang/portable-simd/blob/ceb26115928c5c69b10268fd2f9e500865c142d6/crates/core_simd/src/vector.rs#L80

That was a great addition, but came with the cost that we now need to handle both kinds everywhere that looks at simd.

For example, this test needs to check both

https://github.com/rust-lang/rust/blob/0fd50f3e019dddc47d1d6dbe35c4c1542098d9c5/tests/codegen/simd-intrinsic/simd-intrinsic-transmute-array.rs#L14-L20

And, even more interestingly, it demonstrates that things don't necessarily work the same way between the different approaches.

I propose that we remove the multi-field form.

repr(simd) is not on a stabilization track, the array form is more readable, and nightly users (including core arch) can easily migrate to the array-based form.

By only having one way to do it, we'll simplify things that need to handle or test simd types, like this code that currently has to check for empty simd types twice:

https://github.com/rust-lang/rust/blob/0fd50f3e019dddc47d1d6dbe35c4c1542098d9c5/compiler/rustc_hir_analysis/src/check/check.rs#L890-L910

Mentors or Reviewers

Removing code is generally the easier side of things, so no mentoring should be needed.

@workingjubilee or other portable-simd folks would likely make good reviewers.

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.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[wesleywiser]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted