Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for NEON intrinsics on 32-bit ARM #111800

Open
2 tasks
Amanieu opened this issue May 20, 2023 · 6 comments
Open
2 tasks

Tracking Issue for NEON intrinsics on 32-bit ARM #111800

Amanieu opened this issue May 20, 2023 · 6 comments
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@Amanieu
Copy link
Member

Amanieu commented May 20, 2023

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)1
  • Stabilization PR

Unresolved Questions

Footnotes

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

@Amanieu Amanieu added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels May 20, 2023
azmyrajab added a commit to azmyrajab/polars_ols that referenced this issue Apr 15, 2024
@beetrees
Copy link
Contributor

beetrees commented Jun 21, 2024

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
Copy link
Member

RalfJung commented Sep 2, 2024

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
Copy link
Member

RalfJung commented Sep 2, 2024

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

@beetrees
Copy link
Contributor

beetrees commented Sep 2, 2024

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
Copy link
Member

RalfJung commented Sep 2, 2024

Ah, makes sense. :)

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

@Nugine
Copy link
Contributor

Nugine commented Sep 2, 2024

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

Lynnesbian added a commit to Lynnesbian/faster-hex that referenced this issue Sep 18, 2024
Currently only runs on `aarch64`, because `arm` NEON intrinsics are unstable: rust-lang/rust#111800
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants