Skip to content

Conversation

@Urgau
Copy link
Member

@Urgau Urgau commented May 8, 2025

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 and f128, while GCC doesn't support f16.

r? @tgross35

try-job: aarch64-gnu
try-job: dist-various-1
try-job: dist-various-2

Footnotes

  1. https://www.gnu.org/software///gnulib/manual/html_node/Functions-in-_003cmath_002eh_003e.html

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 8, 2025
@rustbot
Copy link
Collaborator

rustbot commented May 8, 2025

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

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

cc @RalfJung, @oli-obk, @lcnr

@rust-log-analyzer

This comment has been minimized.

@Urgau Urgau force-pushed the minimum-maximum-intrinsics branch from 360cdaf to f308845 Compare May 8, 2025 11:09
Comment on lines 756 to 763
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
}
Copy link
Member

@RalfJung RalfJung May 8, 2025

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

@Urgau Urgau May 8, 2025

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.

Copy link
Member

@RalfJung RalfJung May 8, 2025

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...).

Copy link
Member Author

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.

Copy link
Contributor

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?

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?

Copy link
Member

@scottmcm scottmcm May 9, 2025

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.

@Urgau Urgau force-pushed the minimum-maximum-intrinsics branch from f308845 to 8b600e5 Compare May 8, 2025 13:39
@Urgau Urgau changed the title Use intrinsics for {f16,f32,f64,f64}::{minimum,maximum} operations Use intrinsics for {f16,f32,f64,f128}::{minimum,maximum} operations May 8, 2025
Comment on lines 756 to 763
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
}
Copy link
Contributor

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?

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?

@RalfJung

This comment was marked as resolved.

@RalfJung RalfJung added T-lang Relevant to the language team I-lang-nominated Nominated for discussion during a lang team meeting. I-lang-easy-decision Issue: The decision needed by the team is conjectured to be easy; this does not imply nomination labels May 9, 2025
@RalfJung
Copy link
Member

RalfJung commented May 9, 2025

@rust-lang/lang Never mind, turns out the functions are not actually stable, so we definitely don't need an FCP then. :)

@RalfJung RalfJung removed T-lang Relevant to the language team I-lang-nominated Nominated for discussion during a lang team meeting. I-lang-easy-decision Issue: The decision needed by the team is conjectured to be easy; this does not imply nomination labels May 9, 2025
@Urgau Urgau force-pushed the minimum-maximum-intrinsics branch from 96b7a3d to f63c9d7 Compare May 9, 2025 13:44
@Urgau Urgau force-pushed the minimum-maximum-intrinsics branch from f63c9d7 to 7d53e31 Compare May 9, 2025 14:25
@rust-log-analyzer

This comment has been minimized.

@Urgau Urgau force-pushed the minimum-maximum-intrinsics branch from 7d53e31 to ca9dfb2 Compare May 9, 2025 14:48
@rust-log-analyzer

This comment has been minimized.

@matthiaskrgr
Copy link
Member

@bors r-
#140890 (comment)

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 10, 2025
@Urgau
Copy link
Member Author

Urgau commented May 10, 2025

@bors try

@bors
Copy link
Collaborator

bors commented May 10, 2025

⌛ Trying commit 7f0ae5e with merge b8a7222...

@bors
Copy link
Collaborator

bors commented May 10, 2025

☀️ Try build successful - checks-actions
Build commit: b8a7222 (b8a72228198170e8c3dc3df531635c7bf11c92ae)

@Urgau
Copy link
Member Author

Urgau commented May 10, 2025

It appears that on architecture where LLVM implements custom lowering for llvm.minimum.* and llvm.maximum.*, mainly x86 and aarch64, there a SelectionDAG error on f128 (and only this one). I've opened issues about this on LLVM repo: llvm/llvm-project#139380 and llvm/llvm-project#139381.

I've disabled the lowering to llvm.minimum.f128 and llvm.maximum.f128 for every architectures and instead fallback to our intrinsic fallback. Which is passing CI (the try build above).

@bors r=scottmcm,traviscross,tgross35

@bors
Copy link
Collaborator

bors commented May 10, 2025

📌 Commit 7f0ae5e has been approved by scottmcm,traviscross,tgross35

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 10, 2025
@bors bors merged commit 3c8950c into rust-lang:master May 11, 2025
7 checks passed
@rustbot rustbot added this to the 1.89.0 milestone May 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.