Tracking Issue for NEON fp16 intrinsics

[mrkajetanp]

This is a tracking issue for NEON fp16 intrinsics.
The feature gate for the issue is #![feature(stdarch_neon_fp16)].

This feature depends on the following PRs:

• Add f16 formatting and parsing #127013 for intrinsics-test to be able to compare the results to C++

Public API

// core::arch::aarch64

fn vadd_f16(..);
(...)

Steps

• Implemenation
• Final comment period (FCP)
• Stabilisation PR

Implementation history

TODO

[Amanieu]

Proposing stabilization of intrinsics that use f16xN vector types, but not intrinsics that use f16 directly since that is still blocked on stabilization of f16 (#116909 ).

@rfcbot 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

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.

[adamgemmell]

I did a quick sanity test that the behavioural testing (intrinsic-test, comparing Rust vs Clang) and signature verification (stdarch-verify, comparing the Rust function definitions with the JSON reference file) for these intrinsics was working correctly.

[RalfJung]

FWIW the float16x4_t and float16x8_t types are already stable, and they have incorrect "stable since" information. Also see Zulip.

EDIT: Ah, this was later fixed by rust-lang/stdarch#1818 it seems.