Repository navigation
NEON intrinsics are broken on big-endian #1484
Description
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.h in Clang for more details.
Activity
Disable conversions between portable_simd and stdarch on big-endian ARM
Disable conversions between portable_simd and stdarch on big-endian ARM
RalfJung commentedon Feb 13, 2024
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?
Amanieu commentedon Feb 14, 2024
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.
RalfJung commentedon Feb 14, 2024
Oh I see, so this is a mismatch about the
simd_xintrinsics vs vendor-specific intrinsics? Okay makes sense.OTOH this is good news for portable-simd, seems like there we'll be getting consistent behavior across platforms without extra work then.
Disable conversions between portable_simd and stdarch on big-endian ARM
Disable conversions between portable_simd and stdarch on big-endian ARM
Disable conversions between portable_simd and stdarch on big-endian ARM
Disable conversions between portable_simd and stdarch on big-endian ARM
Disable conversions between portable_simd and stdarch on big-endian ARM
Disable conversions between portable_simd and stdarch on big-endian ARM
Make this crate build on big-endian aarch64.
14 remaining items
RalfJung commentedon Nov 10, 2024
Yeah the test suite is complicated I am afraid -- I was just giving you some pointers that hopefully lead into the right direction. That's all I can offer, sorry. I don't know how the stdarch test suite is set up. I'm afraid I don't think there is such a thing as a simple test program; stdarch offers many thousand operations and has some fancy setup to test them all.
Amanieu commentedon Nov 10, 2024
You can look at the
intrinsic-testcrate in this repo which checks that the intrinsics match the behavior of those same intrinsics in Clang. See our CI script for an example of how to run it.he32 commentedon Nov 10, 2024
OK, I understand. I have found at least some of what needs to be looked at, and I'm trying to follow the various suggestions here. Next will need to be some experimentation etc. We'll see how that goes. Thanks anyway!
jswrenn commentedon Nov 12, 2024
Did something recently happen in this space? Zerocopy's nightly CI started failing this past weekend due to SIMD intrinsic name resolution errors on
aarch64_be-unknown-linux-gnuwhile buildingmemchr. It doesn't look likememchrhas changed; was rustc changed?taiki-e commentedon Nov 12, 2024
@jswrenn That is because rust-lang/rust#132714 bumped memchr without considering aarch64_be is not supported in the latest memchr (BurntSushi/memchr#162).
(According to the author of that rust-lang/rust PR, the memchr bump might be able to be reverted: taiki-e/atomic-maybe-uninit@6ea62cc#commitcomment-148891566)
Jamesbarford commentedon Dec 18, 2024
FWIW I was going to look at getting this working once the new ARM generator PR has gone in
Disable AES-Neon in big-endian ARM due to rust-lang/stdarch#1484
joshlf commentedon Jan 27, 2025
@Jamesbarford Are you still intending to do this work? Just trying to get a sense of timeline so we know whether to wait for the fix or work around it on our end (in zerocopy - see e.g. this build failure).
Jamesbarford commentedon Jan 28, 2025
@joshlf - this, amongst other things, is something I am currently working on. Timeline wise - I would hesitate to commit to anything concrete optimistically I hope fairly soon!
Disable conversions between portable_simd and stdarch on big-endian ARM
Disable conversions between portable_simd and stdarch on big-endian ARM
sysutils/dua-cli: make this build on aarch64eb.
sysutils/dua-cli: make this build on aarch64eb.
sysutils/dua-cli: make this build on aarch64eb.