aarch64-unknown-none-softfloat: ABI unsoundness when enabling "neon" feature

[RalfJung]

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.

For Rust-generated functions we work around this by forcing our own ABI, passing floats either indirectly or via integer registers (#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 #113739)

LLVM issue: llvm/llvm-project#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.

[apiraino]

We don't have target maintainers listed for this target, so maybe that means we can just demote it to tier 3?

I also skimmed the git history for the https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support.md but found nothing. I think it could make sense to demote the target if it's unmaintained. @RalfJung should I mention this question in the next compiler meeting?

Another question: do you think the neon target feature could create undefined behaviours also in other targets? (I don't know how they work)

thanks

EDIT: I feel this comment kind of answers my second question: IIUC the issue is only when the neon target feature is used on compile target with no FPU (softfloats), which by looking at this list it's basically just the one mentioned here.

[RalfJung]

<#131058> was about various issues with the neon target feature; except for this one, they should all be resolved.

[RalfJung]

With #134794 we could fairly easily reject enabling neon specifically on this target. That would fix the ABI issues.

I just wonder, is anyone relying on enabling neon for aarch64-unknown-none-softfloat? Not quite sure whom to ping... @Darksonn for R4L, who else might be using this target?

[ojeda]

Cc @JamieCunliffe (currently, arm64 in the kernel uses --target=aarch64-unknown-none -Ctarget-feature="-neon").