It might be possible to declare that the FP rounding mode at entry to a signal handler, interrupt handler, or other non-linear control flow is unspecified. The hard question for that is whether, on IEEE754 compliant platforms (i.e. not i586/i686), the existing Rust floating point functions change rounding mode anyway - which would make it effectively unspecified already - or whether we can change the declared Rust ABI for signal handlers, interrupt handlers etc to state that rounding mode is unspecified without causing too much ecosystem pain (e.g. because nobody actually cared about rounding mode in signal handlers or interrupt handlers anyway, and can tolerate their FP result being `(0.25_f32).next_up()` instead of `0.25_f32`. This is still a very different situation to the algebraic functions, where you were opting out of certain guarantees for your code; you're instead changing the guarantees for everyone, and that means that the algebraic functions are not automatically a good model for rounding modes.

azalea_99: > I propose implementing it in a way similar to algebraic math optimizations -- by making the compiler aware of such methods so it could optimize away steps 4-6 (provided that steps 3 and 7 use the same rounding mode). However, as far as I understand, that can require the compiler to reorder operations with the same rounding mode close to each other to avoid unnecessary rounding-mode switching. What do you think about this idea? Note that because of how IEEE754 defines reproducibility of results[1], the compiler is very restricted on reordering floating point operations. This is why the algebraic operations exist, because they are explicitly non-reproducible, and thus allow the compiler much more room for optimizing differently. It might be worth considering whether a block structure of some form (e.g. a function that executes a closure with a different rounding mode) is better for representing a different rounding mode than individual functions; that's closer to how IEEE754 works (and thus how compliant hardware works), and unlike the algebraic operations, where you're telling the compiler it can stray further from IEEE754, this is a case where you could well benefit from being close to how IEEE754 actually works. In either case, you'd need to think about how this all interacts with things like signal handlers, Rust panics and other non-linear flow control; you may still decide that separate functions, and the compiler optimizing out the mode switch, is the right answer, but you may not. * * * 1. Reproducible operations in IEEE754 are defined as equivalent to "compute to infinite precision, then round according to the current rounding mode". This restricts reordering of FP operations, because `round(round(a + b) + c)` is different to `round(a + round(b + c))`. ↩︎

Floating point format explorer – binary representations of common floating point formats.