aarch64-unknown-none-softfloat: ABI unsoundness when enabling "neon" feature (tracking issue for `aarch64_softfloat_neon`)

View all comments

Enabling the "neon" target feature on the aarch64-unknown-none-softfloat target is taken by LLVM as a sign that we want to use the hardfloat ABI. That is unfortunate as it makes it UB to link such code against code built for aarch64-unknown-none-softfloat without the "neon" target feature. (Note that it's not "neon" which is problematic but "fp-armv8"; however, the two are tied together by rustc.)

For Rust-generated functions we work around this by forcing our own ABI, passing floats either indirectly or via integer registers (https://github.com/rust-lang/rust/pull/133102). However, this does not help for LLVM-generated calls for builtins/intrinsics, as shown in this example by @beetrees.

We don't have target maintainers listed for this target, so maybe that means we can just demote it to tier 3? (See https://github.com/rust-lang/rust/issues/113739)

LLVM issue: https://github.com/llvm/llvm-project/issues/110632. So far LLVM maintainers seem to not agree that there is a problem here.

@Amanieu unfortunately your proposal for making floats work on that target doesn't quite suffice. :/ We do need some help from LLVM.
@nikic do you have any good ideas for what we could do here? It seems like rejecting enabling "neon" on aarch64-unknown-none-softfloat is the only sound option we have right now, but I worry that may make the Rust-for-Linux folks (among others) unhappy.

Start by reading Rust PR #133102 and the linked LLVM issue #110632, then examine the provided Compiler Explorer example for LLVM-generated builtin or intrinsic calls. A complete resolution must establish a sound treatment of the neon/fp-armv8 feature and the softfloat ABI, with the target's maintenance or tier status addressed.