Clang has a database of type signatures that we can use.
I think we should do something like this, but I would like to defer that discussion. We have a lot of people who just want to use the vendor intrinsics, and we should give them something as soon as possible. I proposed defining these types as opaque so that we have the freedom to do this later. Once we have the vendor intrinsics out the door, we’ll have the time to do it right.
We should make sure that the types I propose here can be replaced with type aliases in the future without breaking existing sources.
FWIW, when we do have the time to do it right, I think we should aim higher than the
Simd<T> construct. I would encourage you and @glaebhoerl to take a closer look at the vector types in the OpenCL language. They have really neat syntax for swizzles and shuffles.
This is correct, although there are some subtle issues on big-endian machines that we don’t need to get into here.
This is exactly what I had in mind with my proposed types. I only ask that we start out with opaque types for the purposes of shipping the vendor intrinsics, and then change them to aliases like this later when we have a better design for the SIMD language support.
Please let’s defer this if at all possible. I think we can do much better than
Simd<T>, but designing that doesn’t have to block the vendor intrinsics. (And I don’t want to derail this already very long topic with that discussion).
It’s worth remembering that we are talking about literally thousands of intrinsics. If this second interface uses different names, it becomes difficult to find anything.
The stack of abstractions in Clang goes like this:
_mm_sad_epu8(__m128i, __m128i) -> __m128i uses
__builtin_ia32_psadbw128(i8x16, i8x16) -> i64x2 which becomes
declare <2 x i64> @llvm.x86.sse2.psad.bw(<16 x i8>, <16 x i8>) in LLVM.
Note how the lower-level abstractions have correct types and only the Intel name defined in the header file has the weird types. That is because it has to be source compatible with the Intel and Microsoft compilers, and the integer types look like that for historical reasons. It can’t be changed now in C compilers without breaking source compatibility.
We don’t have the burden of source compat since all those existing sources are C and C++. So we don’t need to carry that mistake (IMHO) forward.
Rust has excellent searchable documentation too, so as soon as
_mm256_permute2x128_si256 is exposed as a function in the standard library somewhere, it will be trivial to look up its Rust signature.
I agree that the lack of signed / unsigned information is unfortunate. Maybe we can get our hands on a better database than Clang’s?