Tracking issue for stable SIMD in Rust

[alexcrichton]

This is a tracking issue for RFC 2325, adding SIMD support to stable Rust. There's a number of components here, including:

• #[target_feature(enable = ...)]
• Names of accepted target features - currently proposed
• #[cfg(target_feature = ...)]
• is_target_feature_detected! macro
• std::arch naming and submodules

The initial implementation of this is being added in #48513 and the next steps would be:

• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

---

Known issues

• is_target_feature_detected! takes different arguments that #[target_feature]

[scottmcm]

My one request for the bikeshed (which the current PR already does and may be obvious, but I'll write it down anyway): Please ensure they're not all in the same module as things like undefined_behaviour and [un]likely, so that those rust-defined things don't get lost in the sea of vendor intrinsics.

[cuviper]

What will be the story for external LLVM? (lacking MCSubtargetInfo::getFeatureTable())

[alexcrichton]

@scottmcm certainly! I'd imagine that if we ever stabilized Rust-related intrinsics they'd not go into the same module (they probably wouldn't even be platform-specific).

@cuviper currently it's an unresolved question, so if it doesn't get fixed it means that using an external LLVM would basically mean that #[cfg(target_feature = ...)] would always expand to false (or the equivalent thereof)

[hanna-kruppe]

I'd imagine that if we ever stabilized Rust-related intrinsics they'd not go into the same module (they probably wouldn't even be platform-specific).

One option raised in the RFC thread (that I personally quite like) was stabilizing std::intrinsics (only the module), keep the stable rust intrinsics in that module (they can already be imported from that location due to a long-standing bug in stability checking) and put these new platform-specific intrinsics in submodules. IIUC this would also satisfy @scottmcm's request.

To be explicit, under that plan the rustdoc page for std::intrinsics would look like this:

---

Modules

• x86_64
• arm
• ...

Functions

• copy
• copy_nonoverlapping
• drop_in_place
• ...

[alexcrichton]

Another naming idea I've just had. Right now the feature detection macro is is_target_feature_enabled!, but since it's so target specific it may be more apt to call it is_x86_target_feature_enabled!. This'll make it a pain to call on x86/x86_64 though which could be a bummer.

[nox]

Why keep all the leading underscores for the intrinsics? Surely even if we keep the same names as what the vendors chose, we can still remove those signs, right?

[BurntSushi]

The point is to expose vendor APIs. The vendor APIs have underscores. Therefore, ours do too.

[nox]

It is debatable that those underscores are actually part of the name. They only have one because C has no modules and namespacing, AFAICT.

[nox]

I would be happy dropping the topic if it was discussed at length already, but I couldn't find any discussion specific to them leading underscores.

[BurntSushi]

@nox rust-lang/stdarch#212 --- My comment above is basically a summary of that. I probably won't say much else on the topic.

[Centril]

@nox, @BurntSushi Continuing the discussion from there... since it hasn't been mentioned before:

Leading _ for identifiers in rust often means "this is not important" - so just taking the names directly from the vendors may wrongly give this impression.

[alexcrichton]

@nox @Centril the recurring theme of stabilizing SIMD in Rust is "it's not our job to make this nice". Any attempt made to make SIMD different than what the vendors define has ended with uncomfortable questions and intrinsics that end up being left out. To that end the driving force for SIMD intrinsics in Rust is to get anything compiling on stable.

Crates like faster are explicitly targeted at making SIMD usage easy, fast, and ergonomic. The standard library's intrinsics are not intended to be widely used nor use for "intro level" problems. Leveraging the SIMD intrinsics is quite unsafe (due to target feature detection/selection) and can come at a high cost if used incorrectly.

Overall, again, the goal is to not enable ergonomic SIMD in Rust right now, but any SIMD in Rust. Following exactly what the vendors say is the easiest way for us to guarantee that all Rust programs will always have access to vendor intrinsics.

[hanna-kruppe]

I agree that the leading underscores are a C artifact, not a vendor choice (the C standard reserves identifiers of this form, so that's what C compilers use for intrinsics). Removing them is neither "trying to make it nicer/more ergonomic" (it's really only a minor aesthetic difference) nor involves any per-intrinsic judgement calls. It's a dead simple mechanical translation for a difference in language rules, almost as much as __m128 _mm_foo(); is mechanically translated to fn _mm_foo() -> __m128;.

[alexcrichton]

@rkruppe do we have a rock solid guarantee that no vendor will ever in the future add the same name without underscores?

[Centril]

@alexcrichton

@rkruppe do we have a rock solid guarantee that no vendor will ever in the future add the same name without underscores?

Can't speak for CPU vendors, but the probability seems very very low. Why would they add an intrinsic where the difference is only an underscore..? Further, as Rust's influence grows, they might not do this simply because of Rust.

[hanna-kruppe]

A name like mm_foo (no leading underscore at all) is not reserved in the C language, so it can't be used for compiler-supplied extensions without breaking legal C programs. There are a few theoretical possibilities for a vendor to nevertheless create intrinsics without leading underscores:

• they could expose it only in C++ (with namespacing) -- or, for that matter, another language that isn't C
• they could break legal C programs (very unlikely, and I'll eat my hat if GCC or Clang developers accept this)
• A future version of C adds some way of doing namespacing, and people start using it for intrinsics

All extremely unlikely. The first one seems like the only one that doesn't sound like science fiction to me, and if that happens we'd have other problems anyway (such intrinsics may use function overloading and other features Rust doesn't have).

[alexreg]

It is debatable that those underscores are actually part of the name. They only have one because C has no modules and namespacing, AFAICT.

This. The whole point is that the underscore-leading names were chosen so as to specifically not clash with user-defined functions. Which means they should never be using non-underscore names. It's against well-established C conventions. Hence, we should just rename them to follow Rust conventions, with no real chance there will be any name clash in the future, providing the vendors stay sane and respect C conventions.

[alexcrichton]

@Centril "probability seems very very low" is what I would say as well, but we're talking about stability of functions in the standard library, so "low probability" won't cut it unfortunately.

@rkruppe I definitely agree, yeah, but "extremely unlikely" to me says "follow the vendor spec to the letter and we can figure out ergonomics later".

[alexcrichton]

Another point worth mentioning for staying exactly to the upstream spec is that I believe it actually boosts learnability. You'll have instant familiarity with any SIMD/intrinsic code written in C, of which there's already quite a lot!

If we stray from the beaten path then we'll have to have a section of the documentation which is very clear about defining the mappings between intrinsic names and what we actually expose in Rust.

[pythoneer]

I don't think renaming (no leading underscore or any other alteration) is useful. This is simply not the goal and only introduces pain points. I cannot think of a reason other than "i like that more" to justify that. It only introduces the possibility to naming clashes and "very very unlikely" is not convincing because we can prevent this 100% by not doing it altogether.

I think its the best choice to follow the vendor naming schema as close as possible and i think we should even break compatibility if we ever introduce an error in the "public API" without doing some renaming like _mm_intr_a to _mm_intr_a2 and start diverging the exact naming schema introduced by the vendor.

[nox]

@alexcrichton But as @rkruppe said, removing the leading underscore isn't about ergonomics, it's about not porting C defects to Rust blindly.

[nox]

Sorry for the double post, but I also want to add that arguing that a vendor may release an unprefixed intrinsic with the same name as a prefixed one is to me as hypothetical as arguing that bool may not be a single byte on some platform we would like to support.

[pythoneer]

@nox but why stop by the _? We could also fully rename the function with ps and pd into f32 and f64 which would be something "more Rust". Its somewhat arbitrary to just remove the leading underscore. And we could argue back and forth what is ergonomics and what isn't but i don't think there is a very good line to distinguish that to a point every body agrees.

[nox]

@pythoneer Because the name is what the vendor decided, with a leading underscore because of nondescript limitations of C.

[pythoneer]

@nox and the explicit goal of stdsimd is to expose this (however defect) vendor defined interface.

[alexreg]

@nox and the explicit goal of stdsimd is to expose this (however defect) vendor defined interface.

Interface, sure, but not necessarily the naming conventions!

[SparrowLii]

@Amanieu I see that the part about aarch64 and arm in stdarch is still unstable. The main reason for it is the lack of neon instructions? I can help add them if so.

[Amanieu]

Yes that is the main reason why arm/aarch64 is still unstable.

[jrmuizel]

Is it possible to stabilize the existing instructions without waiting for everything to be done?

It looks like rust-lang/cargo#9181 is going to break the use of neon instrinsics in qcms so it would be nice to have a partial solution sooner rather than later.

[jyn514]

@jrmuizel you could send a PR stabilizing those intrinsics; I can't say whether it would be accepted, but if the intrinsics aren't planned to change it seems reasonable to me.

[jrmuizel]

I filed rust-lang/stdarch#1125 to see if it's possible.

[andy-thomason]

I'm happy to help out with SIMD issues as I have extensive knowledge of instruction sets.

Give me a ping if you want to discuss.

[fzyzcjy]

Hi I wonder the current status of SIMD in Rust? I have to write SIMD on ARM chips (android and ios), so I wonder what should I do?

To my best knowledge, I should firstly switch to nightly channel, and then use https://github.com/rust-lang/packed_simd (or should I use https://github.com/rust-lang/portable-simd ?). Is this the suggest way, or is there a better approach?

Thanks for any suggestions!

[Amanieu]

On the nightly channel you can use the NEON intrinsics in std::arch::aarch64/std::arch::arm.

[fzyzcjy]

Thank you!

[V0ldek]

Is there any roadmap or an overview of what remains to bring this to stable?

[Lokathor]

the portable-simd repo has many tracking issues

https://github.com/rust-lang/portable-simd

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting.

This seems to be the tracking issue for target-specific SIMD (not portable SIMD, which is being tracked and developed elsewhere). And we've shipped target-specific SIMD on x86-64 and aarch64. There will always be more CPUs to support, but that doesn't mean this issue needs to remain open indefinitely.

We've shipped this; closing.

[jrmuizel]

For reference the ARM32 stabilization is tracked in #90972

[tmandry]

The unstable book still links to this issue, which is now closed, but the stdsimd feature continues to exist as a catch-all for platform-specific intrinsics that are not stabilized.

Are there any issues tracking unstabilized features on supported platforms (e.g. aes on arm)?

[ajirving]

It's confusing that if you try to use AVX512 intrinsics on stable the compiler error references this closed issue. Is there an issue tracking AVX512 stabilization and would it be possible to reference it rather than this one?

[joshlf]

What is the state of this feature intended to be? It's not clear from the documentation. In particular:

• This documentation page contains a warning that the float32x2_t type is a "nightly-only experimental API", and links to this issue
• The source code linked from that doc page seems to suggest that the type is actually stable (no clue how the stability warning in the rendered documentation got generated...):

  #[cfg_attr(target_arch = "aarch64", stable(feature = "neon_intrinsics", since = "1.59.0"))]
  pub struct float32x2_t(pub(crate) f32, pub(crate) f32);

• When I compile code using the most recent stable toolchain (specifically, cargo check --target=aarch64-unknown-linux-gnu), it succeeds

[pczarn]

@joshlf Looks like it's shown as stable on aarch64 and unstable on other archs. That's what the conditional cfg_attr on stable means. The docs are probably generated for x86_64. That's why you see the warning inside official docs. I am not sure what was really intended. It really does not make sense.

[bkolligs]

What is the status of AVX 512 registers?