Tracking Issue for NEON intrinsics

[Amanieu]

Feature gate: #![feature(neon_intrinsics)]

This is a tracking issue for NEON SIMD intrinsics on ARM and AArch64. These intrinsics can be found in the std::arch::arm and std::arch::aarch64 modules.

Public API

The NEON intrinsics that are covered by this tracking issue consist of all the ARM/AArch64 intrinsics in those modules that start with the letter v. These are checked against the equivalent Clang intrinsics using automated verifiers.

Unresolved Questions

• None yet.

[SparrowLii]

Could we clarify exactly what we're going to do? For example, the feature needs to be added to the rustc?

[Amanieu]

I created an updated list of intrinsics that are missing/broken compared to Clang and the ARM intrinsic database CSV in rust-lang/stdarch#1258. Thanks to @JamieCunliffe for writing the tool to automate the testing of the intrinsics.

AArch64

This looks pretty good. We are only missing:

• ARMv8.3 complex number intrinsics.
• ARMv8.4 dot product intrinsics.
• All intrinsics which use f16 and bf16 types, due to lack of rustc support. (These are not listed in missing_aarch64.txt)
• The vqshlu* intrinsics currently cause an ICE in LLVM. This needs to be investigated and fixed.

I think we can start the process of stabilizing the AArch64 intrinsics now, conditional on fixing the LLVM ICEs. The missing intrinsics can be added later.

ARM

The situation here is a bit uglier and I don't think we can stabilize this as it is.

• Clang and GCC disagree on the type of poly64_t on A32: it's a signed integer in Clang and an unsigned integer in GCC. On AArch64 both compilers use an unsigned integer. I believe GCC has the correct behavior here, but I am not sure. cc @adamgemmell @JamieCunliffe
• The same missing intrinsics in AArch64 are also missing here (ARMv8.3 complex number, ARMv8.4 dot product, f16, bf16). This is not a blocker for stabilization.
• We are missing quite a few intrinsics ("Implemented in stdarch for A64 only, Clang supports both A32/A64"). This must be fixed prior to stabilization.
• We have some intrinsics that seem to be incorrectly implemented ("Failing tests: stdarch has incorrect results compared to Clang"). This must be fixed prior to stabilization.
• Finally we also have a different set of intrinsics which cause an ICE in LLVM. This also needs to be investigated and fixed.

[Amanieu]

As per the report above, I would like to propose the stabilization of all the currently implemented NEON intrinsics on AArch64 only.

@rfcbot fcp merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[JamieCunliffe]

I would say GCC is correct here, in https://github.com/ARM-software/acle/blob/main/main/acle.rst#scalar-data-types poly64_t is an unsigned integer type.

For the LLVM ICE is there a bug for this? I'll take a look into it if no one else has.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔