Mark const SIMD intrinsics as indirectly stable #149648
Conversation
|
cc @rust-lang/wg-const-eval Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr Some changes occurred to the platform-builtins intrinsics. Make sure the cc @antoyo, @GuillaumeGomez, @bjorn3, @calebzulawski, @programmerjake |
rustbot
added
S-waiting-on-review
|
So you plan to soon const-stabilize functions using these intrinsics? |
|
I won't say soon (it would require t-libs-api approval), but yes the plan is eventually to stabilize them |
traviscross
added
the
I-lang-radar
|
Usually we do the t-lang FCP for const intrinsics as part of that stabilization, not preemptively. |
| #[rustc_intrinsic] | ||
| #[rustc_nounwind] | ||
| #[rustc_intrinsic_const_stable_indirect] | ||
| pub const unsafe fn simd_fma<T>(x: T, y: T, z: T) -> T; |
There was a problem hiding this comment.
For this, not even the scalar version is const-stable yet. It seems odd to stabilize the SIMD version before the scalar version.
There was a problem hiding this comment.
More specifically, const-stabilization is in progress at #148052.
There was a problem hiding this comment.
ah ok, then I think it would be better to wait until that lands first
| #[rustc_intrinsic] | ||
| #[rustc_nounwind] | ||
| #[rustc_intrinsic_const_stable_indirect] | ||
| pub const unsafe fn simd_relaxed_fma<T>(x: T, y: T, z: T) -> T; |
There was a problem hiding this comment.
This one is tricky since it is non-deterministic. Also, not even the scalar version is const-stable yet.
There was a problem hiding this comment.
I am ok with not doing it now, we don't use it in stdarch anyway
| #[rustc_intrinsic] | ||
| #[rustc_nounwind] | ||
| #[rustc_intrinsic_const_stable_indirect] | ||
| pub const unsafe fn simd_reduce_max<T, U>(x: T) -> U; |
There was a problem hiding this comment.
We should check the intended and actual semantics of this carefully, given all the recent discussion around the semantics of min and max (see #149537 and also LLVM discussions). In particular, IEEE-754 maxNum is not what we do for $float::max -- do we really want a different semantics here, and do we really have a different semantics here?
There was a problem hiding this comment.
In fact what we currently implement in the interpreter is NOT IEEE-754 maxNum. It is the same as $float::max, which is a mix of IEEE 754-2008 maxNum and IEEE 754-2019 maximumNumber. I don't know if that's what the users of this operation want, and I don't know what the codegen backends are doing.
There was a problem hiding this comment.
I see, LLVM is also very weird in this scenario. It ways llvm.vector.reduce.fmax behaves like an ordered reduction, with the operation being llvm.maxnum -- but this doesn't align exactly with IEEE maxNum. But in x86 stdarch, we only use it for integers (we explicitly avoid using any of the reduce intrinsics in x86 stdarch because the semantics and ordering of the operations don't match exactly with x86)
There was a problem hiding this comment.
I think ideally we'd just not mark it as indirectly stable at all.
Otherwise we'll have to devise some clever ad-hoc plan for how to allow it only for integers.
| #[rustc_intrinsic] | ||
| #[rustc_nounwind] | ||
| #[rustc_intrinsic_const_stable_indirect] | ||
| pub const unsafe fn simd_reduce_min<T, U>(x: T) -> U; |
There was a problem hiding this comment.
This has the same concern as max.
|
r? @RalfJung |
traviscross
added
T-lang
5 participants
recently most SIMD intrinsics were made available in const contexts in #147521. This PR makes the indirectly stable to use in const contexts.
cc @RalfJung @rust-lang/lang @rust-lang/wg-const-eval