Repository: rust
Issue: Tracking Issue for 32-bit ARM DSP intrinsics
Labels: O-Arm,T-libs-api,A-SIMD,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(stdarch_arm_dsp)]`

This is a tracking issue for 32-bit ARM DSP and SIMD32 intrinsics.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::arch::arm
pub struct int8x4_t(i8, i8, i8, i8);
pub struct uint8x4_t(u8, u8, u8, u8);

pub unsafe fn __qadd8(a: int8x4_t, b: int8x4_t) -> int8x4_t;
pub unsafe fn __qsub8(a: int8x4_t, b: int8x4_t) -> int8x4_t;
pub unsafe fn __qsub16(a: int16x2_t, b: int16x2_t) -> int16x2_t;
pub unsafe fn __qadd16(a: int16x2_t, b: int16x2_t) -> int16x2_t;
pub unsafe fn __qasx(a: int16x2_t, b: int16x2_t) -> int16x2_t;
pub unsafe fn __qsax(a: int16x2_t, b: int16x2_t) -> int16x2_t;
pub unsafe fn __sadd16(a: int16x2_t, b: int16x2_t) -> int16x2_t;
pub unsafe fn __sadd8(a: int8x4_t, b: int8x4_t) -> int8x4_t;
pub unsafe fn __smlad(a: int16x2_t, b: int16x2_t, c: i32) -> i32;
pub unsafe fn __smlsd(a: int16x2_t, b: int16x2_t, c: i32) -> i32;
pub unsafe fn __sasx(a: int16x2_t, b: int16x2_t) -> int16x2_t;
pub unsafe fn __sel(a: int8x4_t, b: int8x4_t) -> int8x4_t;
pub unsafe fn __shadd8(a: int8x4_t, b: int8x4_t) -> int8x4_t;
pub unsafe fn __shadd16(a: int16x2_t, b: int16x2_t) -> int16x2_t;
pub unsafe fn __shsub8(a: int8x4_t, b: int8x4_t) -> int8x4_t;
pub unsafe fn __usub8(a: uint8x4_t, b: uint8x4_t) -> uint8x4_t;
pub unsafe fn __ssub8(a: int8x4_t, b: int8x4_t) -> int8x4_t;
pub unsafe fn __shsub16(a: int16x2_t, b: int16x2_t) -> int16x2_t;
pub unsafe fn __smuad(a: int16x2_t, b: int16x2_t) -> i32;
pub unsafe fn __smuadx(a: int16x2_t, b: int16x2_t) -> i32;
pub unsafe fn __smusd(a: int16x2_t, b: int16x2_t) -> i32;
pub unsafe fn __smusdx(a: int16x2_t, b: int16x2_t) -> i32;
pub unsafe fn __usad8(a: int8x4_t, b: int8x4_t) -> u32;
pub unsafe fn __usada8(a: int8x4_t, b: int8x4_t, c: u32) -> u32;

pub struct int16x2_t(i16, i16);
pub struct uint16x2_t(u16, u16);

pub unsafe fn __smulbb(a: int16x2_t, b: int16x2_t) -> i32;
pub unsafe fn __smultb(a: int16x2_t, b: int16x2_t) -> i32;
pub unsafe fn __smulbt(a: int16x2_t, b: int16x2_t) -> i32;
pub unsafe fn __smultt(a: int16x2_t, b: int16x2_t) -> i32;
pub unsafe fn __smulwb(a: int16x2_t, b: i32) -> i32;
pub unsafe fn __smulwt(a: int16x2_t, b: i32) -> i32;
pub unsafe fn __qadd(a: i32, b: i32) -> i32;
pub unsafe fn __qsub(a: i32, b: i32) -> i32;
pub unsafe fn __qdbl(a: i32) -> i32;
pub unsafe fn __smlabb(a: int16x2_t, b: int16x2_t, c: i32) -> i32;
pub unsafe fn __smlabt(a: int16x2_t, b: int16x2_t, c: i32) -> i32;
pub unsafe fn __smlatb(a: int16x2_t, b: int16x2_t, c: i32) -> i32;
pub unsafe fn __smlatt(a: int16x2_t, b: int16x2_t, c: i32) -> i32;
pub unsafe fn __smlawb(a: i32, b: int16x2_t, c: i32) -> i32;
pub unsafe fn __smlawt(a: i32, b: int16x2_t, c: i32) -> i32;
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html