KEMBAR78
Make some float methods unstable `const fn` by eduardosm · Pull Request #130568 · rust-lang/rust · GitHub
Skip to content

Conversation

@eduardosm
Copy link
Contributor

@eduardosm eduardosm commented Sep 19, 2024

Some float methods are now const fn under the const_float_methods feature gate.

I also made some unstable methods const fn, keeping their constness under their respective feature gate.

In order to support min, max, abs and copysign, the implementation of some intrinsics had to be moved from Miri to rustc_const_eval (cc @RalfJung).

Tracking issue: #130843

impl <float> {
    // #[feature(const_float_methods)]
    pub const fn recip(self) -> Self;
    pub const fn to_degrees(self) -> Self;
    pub const fn to_radians(self) -> Self;
    pub const fn max(self, other: Self) -> Self;
    pub const fn min(self, other: Self) -> Self;
    pub const fn clamp(self, min: Self, max: Self) -> Self;
    pub const fn abs(self) -> Self;
    pub const fn signum(self) -> Self;
    pub const fn copysign(self, sign: Self) -> Self;

    // #[feature(float_minimum_maximum)]
    pub const fn maximum(self, other: Self) -> Self;
    pub const fn minimum(self, other: Self) -> Self;

    // Only f16/f128 (f32/f64 already const)
    pub const fn is_sign_positive(self) -> bool;
    pub const fn is_sign_negative(self) -> bool;
    pub const fn next_up(self) -> Self;
    pub const fn next_down(self) -> Self;
}

r? libs-api

try-job: dist-s390x-linux

@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 Sep 19, 2024
@rustbot
Copy link
Collaborator

rustbot commented Sep 19, 2024

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

@jieyouxu jieyouxu added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Sep 19, 2024
@RalfJung
Copy link
Member

r=me on the interpreter and Miri parts.

@eduardosm
Copy link
Contributor Author

I made clamp const too, using an approach similar to #130611 to handle the assert formatting.

@rust-log-analyzer

This comment has been minimized.

@tgross35
Copy link
Contributor

If this is accepted, a tracking issue should be created (for now I set issue = "none").

You can go ahead and do this in advance, I don't think there is any reason these would be rejected

@rust-log-analyzer

This comment has been minimized.

@eduardosm
Copy link
Contributor Author

Created tracking issue: #130843

For f16/f32 methods, I placed commented gates under the same feature as f32/f64 (e.g., is_sign_positive under const_float_classify, next_up under float_next_up_down).

@bors
Copy link
Collaborator

bors commented Oct 4, 2024

☔ The latest upstream changes (presumably #130157) made this pull request unmergeable. Please resolve the merge conflicts.

@eduardosm
Copy link
Contributor Author

I believe is_sign_positive / is_sign_negative do not need the second unstable gate since const_float_classify is now stable.

}
}

enum FloatBinOp {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
enum FloatBinOp {
enum FloatBinIntrinsic {

We use BinOp for the MIR binops, IMO we shouldn't mix up that terminology.

Also please move this above the functions that use it.

@RalfJung
Copy link
Member

RalfJung commented Oct 5, 2024

LGTM from the interpreter side.

r? libs-api

@rustbot rustbot assigned BurntSushi and unassigned joshtriplett Oct 5, 2024
@eduardosm
Copy link
Contributor Author

Rebased to pick #131256 and remove #![feature(f16_const)] and #![feature(f128_const)].

@bors
Copy link
Collaborator

bors commented Oct 12, 2024

☔ The latest upstream changes (presumably #131581) made this pull request unmergeable. Please resolve the merge conflicts.

@tgross35
Copy link
Contributor

tgross35 commented Oct 12, 2024

If libs-api can just okay unstably adding const to the signatures, I'm happy to review the rest.

@rustbot label +I-libs-api-nominated

@rustbot rustbot added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Oct 12, 2024
@BurntSushi
Copy link
Member

The unstable const APIs LGTM (on the basis that we're doing the same for f32 and f64).

@tgross35 tgross35 removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Oct 14, 2024
@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 Oct 15, 2024
@jieyouxu

This comment was marked as resolved.

@bors

This comment was marked as resolved.

@compiler-errors
Copy link
Member

@bors rollup=never

@tgross35
Copy link
Contributor

tgross35 commented Oct 15, 2024

Ah yeah yuck, every function in stdlib that takes a f16 or f128 in the signature still needs #[inline] so LLVM doesn't try to codegen and crash on platforms where that is buggy. This includes the assert_at_const and assert_at_rt functions.

@rust-log-analyzer

This comment was marked as resolved.

@bors

This comment was marked as resolved.

Some float methods are now `const fn` under the `const_float_methods` feature gate.

In order to support `min`, `max`, `abs` and `copysign`, the implementation of some intrinsics had to be moved from Miri to rustc_const_eval.
@eduardosm
Copy link
Contributor Author

Fixed by adding #[inline] to assert_at_const. Tested locally with ./x build --target s390x-unknown-linux-gnu library/core

@RalfJung
Copy link
Member

@bors r=RalfJung,tgross35 rollup

@bors
Copy link
Collaborator

bors commented Oct 15, 2024

📌 Commit c09ed3e has been approved by RalfJung,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 Oct 15, 2024
@RalfJung
Copy link
Member

Ah yeah yuck, every function in stdlib that takes a f16 or f128 in the signature still needs #[inline] so LLVM doesn't try to codegen and crash on platforms where that is buggy. This includes the assert_at_const and assert_at_rt functions.

Wow f16 / f128 are more unstable than I thought.^^ Is there an issue tracking specifically the codegen crashes? Can we have a central workaround instead of dozens of #[inline] everywhere where we will surely forget to remove some?

@tgross35
Copy link
Contributor

Wow f16 / f128 are more unstable than I thought.^^ Is there an issue tracking specifically the codegen crashes? Can we have a central workaround instead of dozens of #[inline] everywhere where we will surely forget to remove some?

The list of platforms where just seeing the types is enough to make LLVM crash is fortunately pretty limited, wasm and arm64ec being some notably more popular exceptions https://github.com/rust-lang/compiler-builtins/blob/cb060052ab7e4bad408c85d44be7e60096e93e38/configure.rs#L53-L77. AIUI however, we need the inline annotations anyway since Cranelift doesn't support the types, and having anything not inline would mean it can't compile std.

I'm not sure what would be better here.

@RalfJung
Copy link
Member

I'm not sure what would be better here.

We can automatically mark functions as inline if they have a f16/f128 argument. 🙈

@tgross35
Copy link
Contributor

That works 😄

@beetrees
Copy link
Contributor

The codegen crashes are currently tracked as part of the big list in the tracking issue at #116909 (comment), but there isn't a separate dedicated tracking issue just for them. Adding a cfg via core/std's build.rs for whether f16/f128 codegen will succeed or not is definitely possible: compiler-builtins already has such a cfg, and std already has a different list for whether f16/f128 tests will pass or not.

@RalfJung
Copy link
Member

Specifically, the logic here, which already makes "small" functions auto-#[inline], could also check the signature.

@bors bors merged commit 2f3f001 into rust-lang:master Oct 15, 2024
6 checks passed
@rustbot rustbot added this to the 1.84.0 milestone Oct 15, 2024
@eduardosm eduardosm deleted the const-float-methods branch October 16, 2024 10:07
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. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.