Proving IEEE-754 2008 compliance for all sqrt/sqrtf implementations on all platforms.

[james7132]

Rust's f32/f64 types specify that they're IEEE-754 2008 compliant, from which the behavior of sqrt is explicitly defined by the standard. The SSE/SSE2 path in both is currently the only target-feature based platform specific alterations in the libm codebase. While these intrinsic based paths are significantly faster, there should be extensive testing to show that these alternative implementations produce identical results across platforms that is consistent with the standard.

For deterministic game networking and simulation stability, we're relying on libm to provide bit-for-bit identical output across multiple targets for common mathematical functions that are not consistent across hardware implementations (i.e. much of the x87 transcendental instructions), and sqrt(f) is a particularly common function to see used.

[Lokathor]

For Background: The f32::sqrt and f64::sqrt methods in std use the compiler intrinsic for sqrt. This means that all sqrt method calls should naturally utilize hardware as much as possible. This means not only on targets with sse/sse2, but also arm, wasm, etc. The conditional compilation in libm::sqrtf and libm::sqrt does use a CPU intrinsic when statically available. However, that code path only exists as an optimization to be used by no_std libraries that need to do a sqrt and so are calling libm directly. Uses of the sqrt methods in std should never end up lowering into a libm call if the hardware supports a sqrt operation.

That said, we welcome improvements to the crate's test suite.