Julia: Consider adding a `VecTuple{N,T}` to hold N `VecElements{T}`s

[m-j-w]

I'm aware of the existence of SIMD.jl. However, I believe the fundamental code generation of SIMD vectors should be supported in an easier way in Julia base itself, and hide some of the details in the wrapping tuple rather than simply by the underlying type.

Thus my proposal would be to define some type VecTuple{N,T} which would essentially be equivalent to current NTuple{N, VecElement{T}}. The difference would be that the VecElement codegen properties would be implicitly applied if needed, but tied to the tuple rather than the element. This way, accessing individual elements of the tuple would not need to go through an additional conversion T <-> VecElement{T}. Currently accessing a single element of an NTuple{N, VecElement{T}} requires x[i].value instead of simply x[i].

Also, requirements for total type size and alignment, or which fundamental types (bitsizes 8 to 64) are permitted at all, would be tied to the specialized tuple. See also #20961.

I'm not suggesting to add all possible operations on SIMD vectors to Julia base. There are certainly too many (think about shuffling, transposing or inversing). This could still all be left to specialized packages for the time being, just changing the kind of how the most fundamental LLVM codegen property is linked to the tuple.

(VecTuple is of course just a placeholder for any convienient name on the matter.)

[vtjnash]

Just as a reminder for others, we don't have VecTuple since Tuple is not defined as a type of abstract vector, so it is a partial clash of terms to talk about a vectorized-tuple.

[eschnett]

One idea for how to proceed would be to create a new package that describes what you think should go into base. Call it e.g. SIMDBase. We can then retarget SIMD to that package, which would -- if your assumption is correct -- simplify SIMD. Once people agree about the functionality provided by SIMDBase, it could be moved into Base.

For example, I wouldn't mind if some of the low-level LLVM calling contortions could be handled elsewhere.

[m-j-w]

For reference, SIMD intrinsic types are also discussed at length here: #2299

I'll try to come up with some feasible concept... might take a bit.