Add simd_relaxed_fma intrinsic #133395
Add simd_relaxed_fma intrinsic #133395
Conversation
rustbot
added
S-waiting-on-review
|
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred to the platform-builtins intrinsics. Make sure the cc @antoyo, @GuillaumeGomez, @bjorn3, @calebzulawski, @programmerjake Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @rust-lang/wg-const-eval Some changes occurred in compiler/rustc_codegen_gcc |
calebzulawski
force-pushed
the
simd_relaxed_fma
branch
from
552ed67 to
e73e9f9
Compare
| /// `T` must be a vector of floats. | ||
| #[cfg(not(bootstrap))] | ||
| #[rustc_nounwind] | ||
| pub fn simd_relaxed_fma<T>(x: T, y: T, z: T) -> T; |
There was a problem hiding this comment.
So this is like fmuladd on scalars? That should be mentioned, and probably it makes sense to copy the doc comment from there.
There was a problem hiding this comment.
Ah I didn't realize there was a scalar version... is it used anywhere?
There was a problem hiding this comment.
to match the scalar version, imo it should be renamed to simd_fmuladd, also to avoid confusion with any fast-math semantics
There was a problem hiding this comment.
It's not used yet, it was added in preparation for exposing corresponding methods on the float types.
There was a problem hiding this comment.
to match the scalar version, imo it should be renamed to simd_fmuladd, also to avoid confusion with any fast-math semantics
That's a pretty bad name though IMO, it is used for the scalar version only because that's how LLVM calls them.
I like relaxed_fma. I don't think it is confusing with fast-math semantics, we don't call those "relaxed" after all.
There was a problem hiding this comment.
hmm, maybe...though I want to say I've seen relaxed suggested for fast math functions...
There was a problem hiding this comment.
though, since it isn't always fused, I think simd_something_mul_add is better than simd_something_fma
There was a problem hiding this comment.
simd_mul_add? simd_relaxed_mul_add?
There was a problem hiding this comment.
yeah, either of those would be ok-ish -- simd_mul_add makes one think of f32::mul_add which is always fused (imo naming f32::mul_add mul_add is a mistake, but there's nothing we can do now...).
No, we already implement |
|
Yeah. This looks correct. Thanks! @bors r+ |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#132723 (Unify `sysroot_target_{bin,lib}dir` handling) - rust-lang#133041 (Print name of env var in `--print=deployment-target`) - rust-lang#133325 (Reimplement `~const` trait specialization) - rust-lang#133395 (Add simd_relaxed_fma intrinsic) - rust-lang#133517 (Deeply normalize when computing implied outlives bounds) - rust-lang#133785 (Add const evaluation error UI test.) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#133395 - calebzulawski:simd_relaxed_fma, r=workingjubilee Add simd_relaxed_fma intrinsic Adds compiler support for rust-lang/portable-simd#387 (comment) r? `@workingjubilee` cc `@RalfJung` is this kind of nondeterminism a problem for miri/opsem?
| @@ -612,6 +612,20 @@ extern "rust-intrinsic" { | |||
| #[rustc_nounwind] | |||
| pub fn simd_fma<T>(x: T, y: T, z: T) -> T; | |||
|
|
|||
| /// Computes `(x*y) + z` for each element, non-deterministically executing either | |||
| /// a fused multiply-add or two operations with rounding of the intermediate result. | |||
There was a problem hiding this comment.
Do we guarantee that the choice made is consistent across all lanes? Or could it happen that some lanes get fused and others not?
I assume this can happen because we want to allow the backend to split a big SIMD op into multiple smaller SIMD ops, and then some may be fused and some may not.
|
sync @bors r- |
bors
added
S-waiting-on-author
…workingjubilee Add simd_relaxed_fma intrinsic Adds compiler support for rust-lang/portable-simd#387 (comment) r? `@workingjubilee` cc `@RalfJung` is this kind of nondeterminism a problem for miri/opsem?
Adds compiler support for rust-lang/portable-simd#387 (comment)
r? @workingjubilee
cc @RalfJung is this kind of nondeterminism a problem for miri/opsem?