I have to agree with you that this doesn't make much sense, but there is a
case where you would want something like that: when the original source
uses NEON intrinsics, and there is no alternative in AltiVec, AVX or even
We encourage people to use NEON intrinsics, as opposed to writing inline
NEON assembly, when the compiler cannot vectorize your code properly. This
may fix the current problem of under-performing forward-incompatible inline
asm, and it does solve the portability issue across ARM sub-architectures
(ex. v7 vs v8), but it doesn't help on portability across entirely
different architectures. Since it's not easy to vectorize every code, and
not desired to have special cases hard-coded in the vectorizer, I don't see
another solution to this problem.
Before, you'd have assembly files with NEON specific code, another with
AltiVec specific and so on, and now you'd have C files with each
intrinsics, which is better. But, as you said yourself, the semantics of
NEON instructions are not the same as other SIMD ISAs, so if you only have
the NEON file and want to create an AltiVec version, you'll have to
understand both pretty well.
If I got it right above, I think it would be better if you could do that
transformation in IR, with a mapping infrastructure between each SIMD ISA.
Something that could represent every possible SIMD instruction, and how
each target represents them, so in one side you read the intrinsics (and
possibly IR operations on vectors), translate to this meta-SIMD language,
then export on the SIMD language that you want.
A tool like this, possibly exporting back to C code (so you can add it to
your project as an one-off pass), would be valuable to all programs that
have legacy hard-coded SSE routines to run on any platform that support
I have no idea how easy would be to do that, let alone if it's at all
possible, but it seems that this is what you want. Correct me if I'm wrong.