Tracking issue for #![feature(const_fn_floating_point_arithmetic)]

[Centril]

Sub-tracking issue for rust-lang/rfcs#911.

This tracks arithmetic for floating point types in const fn. These operations are already stable in const/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 -- only const fn code could be executed both at compile-time and run-time, making possible differences in FP behavior observable. Also see #77745.

Open Questions

• Must a const fn behave exactly the same at runtime as at compile-time? #77745: Must a const fn behave exactly the same at runtime as at compile-time?
• See Our floating point semantics were a mess unsafe-code-guidelines#237 for a collection of issues around floating-point semantics.

[burrbull]

Can from_bits / to_bits be made const fn in respect that #53535 ?

[RalfJung]

One problem with stabilizing floats in consts is that their run-time semantics are broken, and likely unsound: #55131, #73288.

[mqudsi]

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?

[RalfJung]

(I think we are still using the host fpu for a lot of f32/f64 stuff in miri)

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.

f64::powf64

pow is not available during CTFE even unstably, since our softlofat library does not support pow (or at least I couldn't find any support for this operation). So to get pow in const even just on nightly (disregarding all the issues that currently block stabilization), someone would have to first implement pow in softfloats.

[RalfJung]

All the issues around floating-point semantics aside, we do allow floating-point operations in const outside const fn. We also promote floating-point operations, so e.g. &(1.0*2.0) will be evaluated at compile time. So we basically already have to live with whatever our CTFE floating-point semantics are, and we have to be careful with changing it. I don't immediately see how allowing the same operations in const fn would make things any worse... @oli-obk was disallowing this in const fn just done out of abundance of caution, or was there some other concern?

[oli-obk]

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.

[RalfJung]

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.

[oli-obk]

Doesn't ConstProp already use CTFE floats to optimize runtime code?

no, we explicitly opt out of floats.

. I don't think that decision was ever made, was it?

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

[RalfJung]

no, we explicitly opt out of floats.

Oh, interesting.
We do promote floating-point-ops though which is not too different from an optimization. (And I recently tried to disable that and found too many uses. Maybe we could disable it in fn/const fn only but still promote in static/const; not sure if that's worth it.)

[workingjubilee]

@oli-obk

There are much worse things (like missing heap allocations) just assume that no one can make optimizations that solely depend on the constness of a function.

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?

@RalfJung

since the IEEE float spec doesn't always uniquely determine what happens (in particular around NaNs),

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.

[programmerjake]

FiniteFxx could then have const arithmetic where NaN would be represented by None. fxx const arithmetic can then be implemented as unwrapping the result of FiniteFxx arithmetic.

imho having FiniteFxx is fine (though I would keep both +0.0 and -0.0 to match IEEE 754's definition of finite).

imho using FiniteFxx to implement const fxx arithmetic is probably terrible, floats have infinities for a good reason, and conflating them with NaNs is not helpful.

if I were to design const floats for Rust and get consistent cross-architecture results and weren't trying to match any particular architecture, I'd follow more or less what RISC-V, JavaScript, and Java do, and keep all results identical to what IEEE 754 specifies except for NaNs. I'd always have non-pure-bitwise fp ops (so everything but neg, copysign, abs, and friends) produce a known canonical NaN value (e.g. iirc RISC-V picked 0x7FC00000 for f32) everytime they output any NaN.

[scottmcm]

+1 to keeping the infinities -- they're useful, don't have the ambiguity problems of NANs, and don't keep the type from being Ord.

[p-avital]

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: OrdFxx? Any suggestions?

[programmerjake]

They couldn't be called finite anymore though: OrdFxx? Any suggestions?

I've seen them referred to as NonNanF32 (with casing TBD), similar to NonZeroU32

[RalfJung]

Note that we already do allow floating point operations in const/static initializers. It's only const fn where they are currently forbidden.

So something like only allowing NonNanF32 in const would either be a massive breaking change, or we'd still have the strange situation of having different rules in const vs const fn.

[programmerjake]

I'm all for f32/f64 support in const fn, once we figure out the exact semantics, which imho should either match LLVM (which is currently being discussed), or be specified kinda like RISC-V, Java, and JavaScript, as I explained in more detail above in #57241 (comment)

NonNanF32 is just a nice addition that can be pursued independently.

[str4d]

Would it be reasonable, as a stepping stone, to stabilise subsets of what is currently covered by #![feature(const_fn_floating_point_arithmetic)] that can be defined unambiguously (if such subsets exist)? For example, I'd be interested in knowing if impl PartialEq for {f32, f64} could be stabilised independently of the rest of the arithmetic.

My particular motivation is that I have a C FFI that takes a C struct containing an f32, which for lifetime reasons needs to be defined as &'static. I want to provide a nice wrapper type that users can define as constants, and I want to enforce range constraints (namely assert!(value >= 0.0 && value <= 1.0) because this particular value represents a percentage).

[workingjubilee]

My current goal regarding solving this issue is to make progress on allowing to_bits and from_bits in const fn, without addressing any of the other issues involved, and without entailing e.g. resolving const-time NaN semantics or anything like that. This will allow people to build what solutions they may on top of that.

[clarfonthey]

+1 to allowing from_bits and to_bits; for a ratio library I've been working on I craft an f64 by hand since I don't trust hardware to round correctly and having to transmute the result is the only unsafe code in the whole thing.

[matklad]

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.

[nikomatsakis]

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: ***@***.***>

[oli-obk]

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 😆

[RalfJung]

We're finally moving ahead with stabilization here. :)
#128596