NEON intrinsics are broken on big-endian #1484
Comments
stdarch no longer provide SIMD on big-endian ARM due to rust-lang/stdarch#1484
stdarch no longer provide SIMD on big-endian ARM due to rust-lang/stdarch#1484
What exactly does this mean? Is there a bug in LLVM? If so, where is it tracked? Or is the problem that Rust stdarch wants to expose the intrinsics the way they work on hardware, but LLVM doesn't provide those semantics? If so, could that be fixed by doing appropriate translation of indices before calling the intrinsics? |
|
The short answer is that, on big-endian, LLVM portable vectors have a different element ordering than the one in the vector types used by the NEON intrinsics. The C intrinsics work around this by reversing the element ordering in vectors before & after each intrinsic. We need to do the same in stdarch. |
|
Oh I see, so this is a mismatch about the OTOH this is good news for portable-simd, seems like there we'll be getting consistent behavior across platforms without extra work then. |
stdarch no longer provide SIMD on big-endian ARM due to rust-lang/stdarch#1484
stdarch no longer provide SIMD on big-endian ARM due to rust-lang/stdarch#1484
stdarch no longer provide SIMD on big-endian ARM due to rust-lang/stdarch#1484
stdarch no longer provide SIMD on big-endian ARM due to rust-lang/stdarch#1484
stdarch no longer provide SIMD on big-endian ARM due to rust-lang/stdarch#1484
stdarch no longer provide SIMD on big-endian ARM due to rust-lang/stdarch#1484
As noted in rust-lang/stdarch#1484, the NEON intrinsics are broken on big-endian aarch64. This is part of fixing rust to build for & on big-endian aarch64, following up rust-lang/rust#129819.
Neon / SIMD is known to be problematical in rust, ref. rust-lang/stdarch#1484, even though the CPU itself supports it.
This is done by avoiding attempts at using neon / SIMD in big-endian mode by patching some of the vendored crates. Neon / SIMD is known to be problematical in rust, ref. rust-lang/stdarch#1484, even though the CPU itself supports it. I've also tried reporting the memchr fixes upstream, ref. BurntSushi/memchr#162 So far not yet adopted. Zerocopy has also received a pull request: google/zerocopy#1795
Do this by avoiding trying to use neon / SIMD on big-endian aarch64. Neon intrinsics are problematical on big-endian targets, ref. rust-lang/stdarch#1484
These are currently broken because the order of elements inside vectors is reversed on big-endian systems: the ARM ABI requires that element 0 is located at the highest address of the vector type. However LLVM intrinsics expect element 0 to be located at the lowest address.
See https://llvm.org/docs/BigEndianNEON.html and
arm_neon.hin Clang for more details.The text was updated successfully, but these errors were encountered: