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
• Is it safe to omit the aes feature from intrinsics with polynomial types with the GCC backend? Should the p64 functions be gated under aes? stdarch#2109 (comment)

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