powi: Different rounding behaviour between debug and release mode, and across platforms

[tspiteri]

Note: This was deemed a docs issue; see here for more details.

The code below tries to print the minimum positive subnormal number in different ways.

fn main() {
    println!("{:e}", f64::from_bits(1));
    let divided_minimum_normal = 2f64.powi(-1022) * 2f64.powi(-52);
    println!("{:e}", divided_minimum_normal);
    let direct_pow = 2f64.powi(-1022 - 52);
    println!("{:e}", direct_pow);
}

In release mode, this output is given:

5e-324
5e-324
5e-324

In debug mode, this output is given:

5e-324
5e-324
0e0

That is 2f64.powi(-1074) gives different results for release and debug mode. The difference seems to come from LLVM's optimizations, as the IR looks like it is using llvm.powi.f64(2.0, -1074).

I think this is fine. The difference is only in the subnormal range, and I don't think there are any documented guarantees anywhere that are being broken, but I'm posting this issue to make sure.

(This is on both stable 1.42.0 and on nightly.)

[RalfJung]

Cc @hanna-kruppe @joshtriplett

This is surprising to me. Does IEEE not specify powi behavior? Would be interesting to know what the exact LLVM transformation is that is changing behavior here.

Thanks for bringing this up, at the least this needs to be documented better in the reference (like other floating point subtleties, e.g. #55131).

[RalfJung]

FWIW, Miri prints

5e-324
5e-324
0e0

As expected, it matches the debug behavior. However, Miri implements powi using host floats when it really should use soft-float emulation, so this result does not actually mean that much. apfloat does not seem to support soft-float emulation of powi, though.

[hanna-kruppe]

LLVM performs constant folding of this intrinsic using the host libm, but perhaps it performs a different computations? If I'm reading cppreference right, since C++11 std::pow now longer has a pow(double, int) overload but promotes it to pow(double, double), which might use a very different algorithm than a function specialized for integer exponents. Indeed, if I didn't mess this up then godbolt shows the call used by LLVM turning into pow(base, (double)iexp) in C++11 but calling the same function as Rust's powi in C++98: https://godbolt.org/z/7dqUfM

This might just be an LLVM bug accidentally introduced in the move to C++11.

[RalfJung]

Oh, so LLVM should not use std::pow there, it should use some form of powi?

[hanna-kruppe]

I assume that was the intent of the particular casts it already uses, but I don't know if "some form of powi" is available in C++11 or if it would have to be re-implemented.

[tspiteri]

In {GCC,Clang} {C,C++} you could also write __builtin_powi(f, i).

[tspiteri]

Though at least in GCC, the documentation says that __builtin_powi does not have correct rounding guarantees: “Unlike the pow function no guarantees about precision and rounding are made.”

[tspiteri]

Maybe a comment could be added in the documentation of powi in the same spirit of the comment for log, changing

“Using this function is generally faster than using powf”

to

“Using this function is generally faster than using powf, but owing to implementation details the result may not be correctly rounded.”

[RalfJung]

This looks like an LLVM bug, I don't think we should adjust our docs/spec to that.

[ndmitchell]

I've just wasted a few hours, because I followed the documentation and changed a powf to powi, only to find it failed in some corner case tests later on. I don't think it's a great idea to declare that the docs only have to work with a theoretical compiler backend that doesn't exist - if you are going to reference machine/backend specific characteristics like performance, I think it's only fair to include vastly more important factors like correctness.

I would probably move further and make powi an alias for powf until it got fixed...