Tracking issue for #![feature(const_fn_floating_point_arithmetic)]
#57241
Comments
Centril
added
T-lang
Centril
added
the
needs-rfc
|
Can |
RalfJung
changed the title
const fnconst fn (part of const_fn feature gate)
ecstatic-morse
changed the title
const fn (part of const_fn feature gate)const fn (const_fn_floating_point_arithmetic)
ecstatic-morse
changed the title
const fn (const_fn_floating_point_arithmetic)#![feature(const_fn_floating_point_arithmetic)]
|
While one concern with const evaluation of floating point math is that the results may differ from the hardware (I think we are still using the host fpu for a lot of f32/f64 stuff in miri) there is a huge benefit to adding const evaluation of floating point arithmetic for no_std environments where runtime (soft or hard) fp math may be unavailable altogether. In this context, constant evaluation can be a huge boon to embedded developers and significantly raise both ergonomics and code quality by allowing for compile-time substitution of static expressions involving floating point math based off of literal constant parameters without requiring opaque f32/f64 values followed by an outdated comment saying “this is the result of the computation of ....” and without requiring lookup tables that will take up room in the ROM without ever being accessed because the ultimate results are computed dynamically and plugged in at compile-time. This isn’t even arch-specific, eg currently there’s no way to use f64::powf64 without std except via the intrinsic, but that’s not marked const and shouldn’t be anywhere near the current version of core... except it’s actually perfectly fine to use in core/no_std if evaluated at compile-time (and only at compile-time). Would enabling something like that at compile time require an alternative implementation of the intrinsic or a full restructuring of the std/no_std primitives altogether? |
CTFE never uses the host FPU. (Miri-the-tool sometimes does but that is not relevant here.) Floats during CTFE are implemented entirely via "softfloats", i.e., a software-only implementation of IEEE floating point semantics. This means the result is the same no matter the host you use to compile. However, the result might still be different from what would happen on the target since the IEEE float spec doesn't always uniquely determine what happens (in particular around NaNs), and since some targets are not IEEE-compliant.
|
|
All the issues around floating-point semantics aside, we do allow floating-point operations in |
|
Entirely done out of an abundance of caution. We just didn't want to have any discussion at min_const_fn stabilization time, so we avoided it. The only argument against stabilization is that running the same const fn at runtime and at compile time can yield different results, so technically optimizing away a const fn call by evaluating it at optimization time could change program behaviour. There are much worse things (like missing heap allocations) so I think we can safely ignore this argument and just assume that no one can make optimizations that solely depend on the constness of a function. |
|
Doesn't ConstProp already use CTFE floats to optimize runtime code? Also, if this is considered "changing program behavior", that would mean Rust floats would not be specified as "IEEE floats" but as "whatever-the-target-does floats". I don't think that decision was ever made, was it? It would arguably mean that Miri and CTFE are buggy if they diverge from the target behavior. If Rust is specified as using IEEE floats, then the NaN bits are not specified, and it's okay for them to come out either way. With this view, there is no change in program behavior, just a different non-deterministic choice being made. |
no, we explicitly opt out of floats.
It was not, I was just reiterating the argument that was made here. I don't remember who made the argument or whether they thought it an important argument, I just remember that it was easier to punt the decision into the future. I personally think we should just stabilize floats in const fn |
Oh, interesting. |
I am not sure I understand the first half of this sentence. What do you mean by missing heap allocations? And are there actually any such optimizations?
Which are you thinking of in particular? IEEE754-2008 adds clauses that define a few NaN-related behaviors for floating point. re: the overall subject, I think it is possible to make Rust floats have a reasonably Rust-defined behavior so I do not think we should blink here, at least not just yet. |
|
+1 to keeping the infinities -- they're useful, don't have the ambiguity problems of NANs, and don't keep the type from being |
|
My reason for trimming all these values was to make certain that not ambiguity ever exists, but I'm also fine with keeping -0.0 and infinities if the people with more knowledge of floats confirm that there aren't any operations that may pick arbitrarily between them. They couldn't be called finite anymore though: |
I've seen them referred to as |
|
Note that we already do allow floating point operations in const/static initializers. It's only So something like only allowing |
|
I'm all for
|
|
Would it be reasonable, as a stepping stone, to stabilise subsets of what is currently covered by My particular motivation is that I have a C FFI that takes a C struct containing an |
|
My current goal regarding solving this issue is to make progress on allowing |
|
+1 to allowing |
This PR adds a new `rems_from_px` helper function that can be used to compute rem values based on a pixel value. This is something we do fairly commonly, where we want to express a size that is a given pixel size at the base rem size (e.g., "14px when the rem size is 16px"). `rems_from_px` helps make the intent more explicit, as well as prevent the base rem size from being duplicated everywhere. Note: Ideally we would want `rems_from_px` to be `const`, but that depends on rust-lang/rust#57241. Release Notes: - N/A
|
One small stabilizable subset is In my use-case (implementing something like |
|
This seems pretty reasonable.
…On Sun, Jun 16, 2024, at 5:58 AM, Alex Kladov wrote:
One small stabilizable subset is `is_nan` function --- regardless of which NaN value a particular implementation uses, they all agree on the set of values considered NaN.
In my use-case (implementing something like `NonNanF64`), `is_nan` is the only `const fn` I need.
—
Reply to this email directly, view it on GitHub <#57241 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABF4ZWNGE4LDHHTKWIFWPLZHVOSXAVCNFSM4GMWX322U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJXGEZTMNRXGA2Q>.
You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>
|
|
I would prefer to just go all in and land rust-lang/rfcs#3514 Adding exceptions for individual functions requires extra logic and will just cause us to spend a lot of time on discussing individual items edit: I "made progress" on that RFC by pinging all the T-lang members that have unchecked boxes 😆 |
|
We're finally moving ahead with stabilization here. :) |
jhpratt
changed the title
#![feature(const_fn_floating_point_arithmetic)]
jhpratt
changed the title
#![feature(const_fn_floating_point_arithmetic)]
…rithmetic, r=nnethercote stabilize const_fn_floating_point_arithmetic Part of rust-lang#128288 Fixes rust-lang#57241 The existing test `tests/ui/consts/const_let_eq_float.rs` ([link](https://github.com/RalfJung/rust/blob/const_fn_floating_point_arithmetic/tests/ui/consts/const_let_eq_float.rs)) covers the basics, and also Miri has extensive tests covering the interpreter's float machinery. Also, that machinery can already be used on stable inside `const`/`static` initializers, just not inside `const fn`. This was explicitly called out in rust-lang/rfcs#3514 so in a sense t-lang just recently already FCP'd this, but let's hear from them whether they want another FCP for the stabilization here or whether that was covered by the FCP for the RFC. Cc `@rust-lang/lang` ### Open items - [x] Update the Reference: rust-lang/reference#1566
Rollup merge of rust-lang#128596 - RalfJung:const_fn_floating_point_arithmetic, r=nnethercote stabilize const_fn_floating_point_arithmetic Part of rust-lang#128288 Fixes rust-lang#57241 The existing test `tests/ui/consts/const_let_eq_float.rs` ([link](https://github.com/RalfJung/rust/blob/const_fn_floating_point_arithmetic/tests/ui/consts/const_let_eq_float.rs)) covers the basics, and also Miri has extensive tests covering the interpreter's float machinery. Also, that machinery can already be used on stable inside `const`/`static` initializers, just not inside `const fn`. This was explicitly called out in rust-lang/rfcs#3514 so in a sense t-lang just recently already FCP'd this, but let's hear from them whether they want another FCP for the stabilization here or whether that was covered by the FCP for the RFC. Cc ``@rust-lang/lang`` ### Open items - [x] Update the Reference: rust-lang/reference#1566
…, r=nnethercote stabilize const_fn_floating_point_arithmetic Part of rust-lang/rust#128288 Fixes rust-lang/rust#57241 The existing test `tests/ui/consts/const_let_eq_float.rs` ([link](https://github.com/RalfJung/rust/blob/const_fn_floating_point_arithmetic/tests/ui/consts/const_let_eq_float.rs)) covers the basics, and also Miri has extensive tests covering the interpreter's float machinery. Also, that machinery can already be used on stable inside `const`/`static` initializers, just not inside `const fn`. This was explicitly called out in rust-lang/rfcs#3514 so in a sense t-lang just recently already FCP'd this, but let's hear from them whether they want another FCP for the stabilization here or whether that was covered by the FCP for the RFC. Cc ``@rust-lang/lang`` ### Open items - [x] Update the Reference: rust-lang/reference#1566
and others
Sub-tracking issue for rust-lang/rfcs#911.
This tracks arithmetic for floating point types in
const fn. These operations are already stable inconst/static, and are also being promoted on stable (&(1.2*2.1)has lifetime'static). However, in all of these situations, the code is definitely executed at compile-time -- onlyconst fncode could be executed both at compile-time and run-time, making possible differences in FP behavior observable. Also see #77745.Open Questions
const fnbehave exactly the same at runtime as at compile-time? #77745: Must aconst fnbehave exactly the same at runtime as at compile-time?The text was updated successfully, but these errors were encountered: