You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a number of portable SIMD intrinsics in core::intrinsics::simd. The advantage of using those is that they have to only be implemented once by non-LLVM backends (Miri, cranelift, gcc) and then they work consistently across all architectures. The x86 parts of stdarch thankfully make good use of them, which heavily reduces the number of intrinsics Miri and the other backends have to special-case by hand.
It would be good to do the same for aarch64. AFAIK aarch64 has completely standard float semantics including the behavior on subnormals, so there shouldn't be a reason to use architecture-specific intrinsics. (arm-32 is a different case since the neon intrinsics there flush subnormals to 0, which makes it technically not correct to use the portable intrinsics. But also at least LLVM doesn't implement the portable intrinsics properly on arm-32 so they actually do flush subnormals, except if optimizations kick in in which case we can get unsoundness.)
The text was updated successfully, but these errors were encountered:
It would be good to do the same for aarch64. AFAIK aarch64 has completely standard float semantics including the behavior on subnormals, so there shouldn't be a reason to use architecture-specific intrinsics
We have a number of portable SIMD intrinsics in
core::intrinsics::simd
. The advantage of using those is that they have to only be implemented once by non-LLVM backends (Miri, cranelift, gcc) and then they work consistently across all architectures. The x86 parts of stdarch thankfully make good use of them, which heavily reduces the number of intrinsics Miri and the other backends have to special-case by hand.It would be good to do the same for aarch64. AFAIK aarch64 has completely standard float semantics including the behavior on subnormals, so there shouldn't be a reason to use architecture-specific intrinsics. (arm-32 is a different case since the neon intrinsics there flush subnormals to 0, which makes it technically not correct to use the portable intrinsics. But also at least LLVM doesn't implement the portable intrinsics properly on arm-32 so they actually do flush subnormals, except if optimizations kick in in which case we can get unsoundness.)
The text was updated successfully, but these errors were encountered: