Tracking issue for SIMD support

[alexcrichton]

This is a tracking issue for the unstable core_simd feature in the standard library. SIMD support is quite a thorny topic, but it's largely covered in rust-lang/rfcs#1199, being implemented in #27169, and @huonw will be creating an external crate for full-fledged SIMD support.

cc @huonw

[pnkfelix]

Note that #26403 may well be a blocker issue for 100% safe + composable SIMD

[aturon]

This issue now tracks the simd, simd_ffi, and repr_simd features.

[huonw]

Status update:

In the compiler:

• there is support for a lot of the intel x86/x86-64 intrinsics, but none of the AMD-specific ones
• it also has pretty much all the ARM & AArch64 NEON ones
• other targets have essentially no support
• some of the fanciest intrinsics are missing, especially (IIRC) some of the ARM pointer ones
• the cfg(target_feature = "...") detection is subpar, e.g. it doesn't detect features when an explicit -C target-cpu="..." is set, it doesn't handle disabling features like -C target-feature="-sse2", nor does it handle (AFAICT) for custom target specs

In https://github.com/huonw/simd:

• the cross-platform API is mostly there, for x86, ARM and AArch64
• a small number of platform-intrinsics are exposed, but not a lot
• the autogenerator (in etc) should be upgraded to handle emitting the actual wrappers as well as the raw extern blocks that it can currently do
• this probably makes most sense after rewriting it into Rust, as a proper cargo binary checking in Cargo.lock and everything, using e.g. libs from crates.io (this is fine, as the binary is not part of the normal build process, it is only run when someone decides to)

I'm intending to work on the simd crate first, starting with the rewrite of the autogenerator, but I've currently got a thesis to work on.

[bstrie]

@huonw How's the thesis going? :) Any progress on this issue, to relay to those interested in SIMD stabilization?

[alexcrichton]

@BurntSushi, @nikomatsakis, and I talked about this recently at the work week, and our thoughts are:

• The original strategy of stabilizing the small pieces (intrinsics + #[repr(simd)]) in the compiler is probably the best way forward here. More experimentation can happen in the simd crate, but those are at least the bare bones for moving forward.

• Specifically with intrinsics, we probably want to stabilize defining them in a different fashion, specifically:

  #[simd_intrinsic = "name"] 
  pub fn foo(a: A, b: B) -> C {
      foo(a, b)
  }

  That is, we'd probably stabilize a new #[simd_intrinsic] (ish) attribute whose name would closely follow the standard naming conventions (e.g. those in C compilers). The function would look like normal Rust and look like it recurses into itself but the compiler would understand that direct calls to the function are actually implemented inline, so this isn't actually infinite recursion.

• The "structural typing" of the intrinsics is relatively ok. That is, the compiler can verify any definition is correct, even though each definition may be slightly different (e.g. any 32-bit x 4 value could show up perhaps). The bad part, however, is that not all intrinsics can be verified. For example the simd_lt intrinsic can have any number of SIMD types instantiated, but a pairing like String and Vec<u8> would be nonsensical. This may be difficult to solve in a "pure" fashion but may be worth stomaching to stabilize the SIMD intrinsics (which in general should never be called in favor of the simd crate itself)

• Specifically with #[repr(simd)], we may want to remove support for tagging a generic structure. This does not appear to be used in the simd crate today and may not be necessary at all, in which case it's probably just complications that we don't want to have to think about today.

• One possible route with the intrinsics would be a thought by @arielb1 where any illegal instantiation of type parameters just causes the intrinsic to codegen as a trap, which means that any instantiation is possible and some would just fail at runtime (which would need to be avoided anyway).

All of this was discussed hopefully with an eye to start the process of stabilization soon-ish, and then we can all get SIMD on stable Rust!

cc @eddyb, you likely have many opinions as well!

[eddyb]

@alexcrichton Ahh, I ignored the multiple-definition option in my recent comment.
I think it's a great solution for integer and floating-point intrinsics, but I didn't consider stabilization of any intrinsic to be possible, hence why I tried to only think of options where libcore hosts all intrinsics.

I am still wary about stabilizing intrinsics, but #[simd_intrinsic] seems focused in scope, so I can see how that works. Although, would it be restricted to things that are definitely about SIMD?
There are various platform intrinsics that don't do anything with vectors, such as prefetch.

Other than that, this seems like a good move forward, without the complexities I was worried about.

[alexcrichton]

@eddyb hm yeah I'm not sure if #[simd_intrinsic] is the best name, certainly up for debate! I would figure that all intrinsics would be defined through a similar mechanism, but the SIMD intrinsics were namespaced somehow so they're the only ones that we stabilize. I wouldn't want to stabilize, for example, intrinsics like prefetch (for now).

[BurntSushi]

There are other useful intrinsics like crc32 that are explicitly part of SSE 4.2 but aren't necessarily SIMD.

[alexcrichton]

Oh interesting! I'd be ok punting on those for now in favor of just dealing with the SIMD pieces, but we can relatively easily reevaluate to do something different though.

[nikomatsakis]

So I had a really interesting conversation with @sunfishcode on the topic of SIMD, and in particular the design of SIMD in WASM. The high-level summary was two points:

1. The current breakdown (platform-specific intrinsics, a portable layer atop) is a good one.
2. Since we modeled the SIMD crate on the JS SIMD designs, which are now being incorporated into WASM, it will align well with the WASM design. Code that can be expressed in terms of the simd crate will thus also be a good candidate for compiling to WASM.

Some other interesting points that he raised:

1. SIMD has many audiences with diverse needs, and you can't necessarily accommodate them all very well with just one API:

• codec authors want the raw intrinsics because they use them in clever and unexpected ways;
• HPC people want higher-level abstractions but don't need access to every trick in the book;
• high-performance demands also require raw intrinsics, because they don't mind investing the time to reshape the algorithm for each platform.

1. One way to support these diverse needs, which has been considered for WASM, is to offer the "union" of features across platforms, but offer a way to query which features are "fast" (the idea is that the "slow" features will be emulated). In Rust I would expect we may want similar things, though perhaps the "slow" paths would just trap? (It's probably a bug if you actually wind up executing one of them.)