Open Amanieu opened 1 year ago
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.
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.
Note that this feature is currently unsound due to https://github.com/rust-lang/rust/issues/129880.
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.
Ah, makes sense. :)
Once https://github.com/rust-lang/rust/pull/127731 lands, we should probably also require NEON when passing vectors to/from non-Rust-ABI functions.
Another unsoundness due to codegen: https://github.com/rust-lang/stdarch/issues/1217
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 letterv
.Steps / History
Unresolved Questions