Tracking Issue for NEON intrinsics on 32-bit ARM

[Amanieu]

Feature gate: #![feature(stdarch_arm_neon_intrinsics)]

This is a tracking issue for the NEON intrinsics in core::arch::arm. This was split off from #90972 which tracked the AArch64 NEON intrinsics which have now been stabilized.

Public API

Everything in core::arch::arm that starts with the letter v.

Steps / History

• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Can we fix the unsoundness? 32-bit ARM NEON intrinsics are unsound due to subnormal flushing #129880

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[beetrees]

In #126555 all SIMD types have been changed to require neon to be enabled when they are used as an input or output of inline ASM (even if the underlying register does not require neon) as LLVM fails to compile using them as ASM inputs/outputs otherwise.

[RalfJung]

In #126555 all SIMD types have been changed to require neon to be enabled (even if the underlying register does not) as LLVM fails to compile using them as ASM inputs/outputs otherwise.

So what happens when I use the type and don't have NEON enabled?
I can't see anything in that PR that would then emit an error or so.

[RalfJung]

Note that this feature is currently unsound due to #129880.

[beetrees]

In #126555 all SIMD types have been changed to require neon to be enabled (even if the underlying register does not) as LLVM fails to compile using them as ASM inputs/outputs otherwise.

So what happens when I use the type and don't have NEON enabled? I can't see anything in that PR that would then emit an error or so.

I appear to have missed a few words: the PR changes it so that NEON is required to use the SIMD types as inputs or outputs of inline assembly. Non-inline-assembly uses are unaffected. I've updated the original comment.

[RalfJung]

Ah, makes sense. :)

Once #127731 lands, we should probably also require NEON when passing vectors to/from non-Rust-ABI functions.

[Nugine]

Another unsoundness due to codegen: rust-lang/stdarch#1217

[eirnym]

#127731 has been merged in October 2024, any updates on this one?

[Jamesbarford]

I noticed that the concerns around NEON requirements for inline assembly and non-Rust ABI functions have been addressed, and #127731 has already landed.

Given that the API of these intrinsics will not change further; I've prepared a PR (which I haven't yet opened) to move forward with stabilisation. The PR also includes improvements to the documentation of these intrinsics. Would it be possible to move forward with this?

The soundness issue appears to be endemic to any platform, possibly even any compiler using LLVM as a backend as the same issue is observed in C/C++ when using LLVM. Given this, it seems to be a separate problem from stabilizing the API of these intrinsics.

[Amanieu]

The first thing that needs to be done before any stabilization here is cleaning up and stabilizing the target features for AArch32. This will be needed for any of these intrinsics to actually be called.

[RalfJung]

The soundness issue appears to be endemic to any platform

No, this is an ARM-32 issue. Most¹ other platforms implement floating-points properly, without mandatory subnormal flushing.

So I am not happy with the idea of "let's just hope this soundness issue disappears by itself later". We shouldn't add operations to Rust that we know are unsound without a plan for how to make them sound.

Footnotes

1. x86-32 being the other notable exception. But there the SIMD intrinsics are the sane ones, it's the basic scalar operations that misbehave, so the situation is somewhat reversed. ↩

[Jamesbarford]

No, this is an ARM-32 issue.

I initially thought the same issue affected x86 32-bit, but after scrolling through the ticket, it seems like it may possibly have been resolved: llvm/llvm-project#89885.

That said, I could be wrong, changing the rounding mode of floats appears to cause a similar issue regardless of Arm-32: rust-lang/unsafe-code-guidelines#471 (comment)

I completely understand your concern about not introducing unsound behavior into Rust. However, stabilizing the API for Neon intrinsics seems like a separate matter from resolving these issues. We should certainly document this issue when using them, but I thought the stabilization process was more about the API design rather than its implementation?

[RalfJung]

changing the rounding mode of floats appears to cause a similar issue regardless of Arm-32

Sure, if you call the deprecated, unsafe, and documented-to-be-unsound-never-use-this operations that change the rounding mode then you get in trouble. That's multiple light years away from "I used a normal, maybe even safe NEON intrinsic and got unsoundness".

I thought the stabilization process was more about the API design rather than its implementation?

Clearly we wouldn't stabilize something whose implementation is incomplete or buggy, no matter how sure we are about the API -- in particular if there are questions about how a correct implementation could even be achieved.