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.