Add a SIMD vector type

[pcwalton]

We should be able to use the LLVM support for SIMD vector types. There are two possibilities: (a) an intrinsic type (lang item) which the compiler knows about; (b) auto-promote tuples of the appropriate type to SIMD.

[eholk]

I kind of like the idea of auto-promoting tuples. What about generating SIMD code for fixed length vectors?

[graydon]

Two sub questions: one is whether we'll generate simd moves etc. when moving vector-like structures around on simd-capable target archs; the other is whether we define vector-scalar and/or vector-vector operations, using simd as possible.

I think "yes" on both. Both should be defined in terms of simple rust tuple types, both should just fall back to scalar modes when simd is not available on the target. Possibly best surfaced to (eg.) stdlib traits via per-target named intrinsics; depends how they surface in llvm.

[eholk]

I was thinking about this some more, and we may not need much language support at all. If we expose LLVM's SIMD instructions through intrinsics, we could provide overloaded operators for things like int slices, float slices, etc., that use the appropriate SIMD instructions in their implementation. I'm not sure how well this plays with coherence though.

If I remember right, LLVM's SIMD instructions are really flexible, but may not correspond to anything on the machine itself. For example, I think it's legal to write a 1000-wide vector add instruction. I'm not sure whether LLVM would just fail in this case, or if it would try to generate equivalent code given the available vector instructions.

[dherman]

There's a lot of good prior work to look into on the https://github.com/mozilla/rust/wiki/Lib-simd wiki page.

I've also just added a new paper that just came out from SPJ's group: Haskell Beats C Using Generalized Stream Fusion.

[dobkeratops]

one question about auto promoting tuple types is alignment, you want simd types to be aligned in memory, but is the same always true for tuples?
also simd sometimes behaves differently in the processors pipeline, as an extreme example the powerpc in 360/ps3 had awful issues getting data or even condition codes for branching back from SIMD pipeline into the regular one.(i know they're on the way out) there were cases where scalar code was faster. SIMD might be better as a deliberate decision. I think x86 doesn't suffer from this sort of thing though.

[emberian]

Still relevant, being worked on by @sanxiyn last I knew