-
-
Notifications
You must be signed in to change notification settings - Fork 14.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
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
minandmax, @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
minandmax, @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.
|
@bors try |
|
☀️ Try build successful - checks-actions |
|
It appears that on architecture where LLVM implements custom lowering for I've disabled the lowering to @bors r=scottmcm,traviscross,tgross35 |
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
f16andf128, 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 ↩