-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Use intrinsics for {f16,f32,f64,f128}::{minimum,maximum}
operations
#140792
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
base: master
Are you sure you want to change the base?
Conversation
Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri Some changes occurred in compiler/rustc_codegen_gcc Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred to the CTFE machinery |
This comment has been minimized.
This comment has been minimized.
360cdaf
to
f308845
Compare
library/core/src/num/f16.rs
Outdated
if self > other { | ||
self | ||
} else if other > self { | ||
other | ||
} else if self == other { | ||
if self.is_sign_positive() && other.is_sign_negative() { self } else { other } | ||
} else { | ||
self + other | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be worth preserving this as "fallback" implementation (by giving the intrinsic a body)? Then const-eval wouldn't need an implementation at all, and also cranelift and GCC would not need any extra work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, but it's not currently done min
and max
, @tgross35 was that intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
min
and max
are way older than our ability to have fallback bodies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but as part of adding f16
and f128
we could have added a fallback, but it wasn't done. Hence my question if it was intentional that fallback bodies haven't been added.
Also the minnum16
and minnum128
intrinsics are quite recent, idk if we had already had fallback body.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even the f16/f128 ones might be older than fallback bodies. Also they were obviously just made to be consistent with the f32/f64 ones (hence the terrible name...).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added a fallback for {minimum,maximum}{16,128}
, GCC and Cranelift should have full support.
I didn't touched const-eval as we have the necessary support in rustc_apfloat
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, but it's not currently done
min
andmax
, @tgross35 was that intentional?
To follow up, when I did the original implementation I tried to keep things as similar as possible to the existing float types. Maybe it makes sense to update those later?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the more things that can have fallback MIR the better -- it means they work for out-of-tree backends too, for example. (And might help tools like kani too, to not have to manually handle them in verifiers.)
As was mentioned, it's just that for a long time it wasn't possible to give things fallback MIR, so there's a big backlog.
f308845
to
8b600e5
Compare
{f16,f32,f64,f64}::{minimum,maximum}
operations{f16,f32,f64,f128}::{minimum,maximum}
operations
library/core/src/num/f16.rs
Outdated
if self > other { | ||
self | ||
} else if other > self { | ||
other | ||
} else if self == other { | ||
if self.is_sign_positive() && other.is_sign_negative() { self } else { other } | ||
} else { | ||
self + other | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, but it's not currently done
min
andmax
, @tgross35 was that intentional?
To follow up, when I did the original implementation I tried to keep things as similar as possible to the existing float types. Maybe it makes sense to update those later?
This comment was marked as resolved.
This comment was marked as resolved.
@rust-lang/lang Never mind, turns out the functions are not actually stable, so we definitely don't need an FCP then. :) |
96b7a3d
to
f63c9d7
Compare
f63c9d7
to
7d53e31
Compare
This comment has been minimized.
This comment has been minimized.
7d53e31
to
ca9dfb2
Compare
This comment has been minimized.
This comment has been minimized.
ca9dfb2
to
5482ba9
Compare
This comment has been minimized.
This comment has been minimized.
5482ba9
to
4a9f2b4
Compare
4a9f2b4
to
a6b6316
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
a6b6316
to
dc69020
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me as well :)
@bors r=scottmcm,traviscross,tgross35 |
…r=scottmcm,traviscross,tgross35 Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations This PR creates intrinsics for `{f16,f32,f64,f64}::{minimum,maximum}` operations. This wasn't done when those operations were added as the LLVM support was too weak but now that LLVM has libcalls for unsupported platforms we can finally use them. Cranelift and GCC[^1] support are partial, Cranelift doesn't support `f16` and `f128`, while GCC doesn't support `f16`. r? `@tgross35` [^1]: https://www.gnu.org/software///gnulib/manual/html_node/Functions-in-_003cmath_002eh_003e.html
Rollup of 10 pull requests Successful merges: - rust-lang#129334 (Implement (part of) ACP 429: add `DerefMut` to `Lazy[Cell/Lock]`) - rust-lang#135015 (Partially stabilize LoongArch target features) - rust-lang#138736 (Sanitizers target modificators) - rust-lang#139562 (rustdoc: add a handle that makes sidebar resizing more obvious) - rust-lang#140151 (remove intrinsics::drop_in_place) - rust-lang#140660 (remove 'unordered' atomic intrinsics) - rust-lang#140783 (Update documentation of OnceLock::get_or_init.) - rust-lang#140789 (Update hermit-abi to 0.5.1) - rust-lang#140792 (Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations) - rust-lang#140862 (Enable non-leaf Frame Pointers for Arm64EC Windows) r? `@ghost` `@rustbot` modify labels: rollup
…r=scottmcm,traviscross,tgross35 Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations This PR creates intrinsics for `{f16,f32,f64,f64}::{minimum,maximum}` operations. This wasn't done when those operations were added as the LLVM support was too weak but now that LLVM has libcalls for unsupported platforms we can finally use them. Cranelift and GCC[^1] support are partial, Cranelift doesn't support `f16` and `f128`, while GCC doesn't support `f16`. r? `@tgross35` [^1]: https://www.gnu.org/software///gnulib/manual/html_node/Functions-in-_003cmath_002eh_003e.html
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#129334 (Implement (part of) ACP 429: add `DerefMut` to `Lazy[Cell/Lock]`) - rust-lang#139562 (rustdoc: add a handle that makes sidebar resizing more obvious) - rust-lang#140151 (remove intrinsics::drop_in_place) - rust-lang#140660 (remove 'unordered' atomic intrinsics) - rust-lang#140783 (Update documentation of OnceLock::get_or_init.) - rust-lang#140789 (Update hermit-abi to 0.5.1) - rust-lang#140792 (Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations) - rust-lang#140879 (1.87.0 release notes: remove nonsensical `~` operator) r? `@ghost` `@rustbot` modify labels: rollup
@bors try |
⌛ Trying commit 7f0ae5e with merge b8a72228198170e8c3dc3df531635c7bf11c92ae... |
…<try> Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations This PR creates intrinsics for `{f16,f32,f64,f64}::{minimum,maximum}` operations. This wasn't done when those operations were added as the LLVM support was too weak but now that LLVM has libcalls for unsupported platforms we can finally use them. Cranelift and GCC[^1] support are partial, Cranelift doesn't support `f16` and `f128`, while GCC doesn't support `f16`. r? `@tgross35` try-job: aarch64-gnu try-job: dist-various-1 try-job: dist-various-2 [^1]: https://www.gnu.org/software///gnulib/manual/html_node/Functions-in-_003cmath_002eh_003e.html
This PR creates intrinsics for
{f16,f32,f64,f64}::{minimum,maximum}
operations.This wasn't done when those operations were added as the LLVM support was too weak but now that LLVM has libcalls for unsupported platforms we can finally use them.
Cranelift and GCC1 support are partial, Cranelift doesn't support
f16
andf128
, while GCC doesn't supportf16
.r? @tgross35
try-job: aarch64-gnu
try-job: dist-various-1
try-job: dist-various-2
Footnotes
https://www.gnu.org/software///gnulib/manual/html_node/Functions-in-_003cmath_002eh_003e.html ↩