Rollup merge of #114813 - RalfJung:fpu-control, r=Amanieu

explain why we can mutate the FPU control word

This is usually not allowed (see https://github.com/rust-lang/stdarch/pull/1454), but here we have a special case.
This commit is contained in:
Matthias Krüger 2023-09-05 15:16:48 +02:00 committed by GitHub
commit 781253bc32
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 12 additions and 0 deletions

View File

@ -8,6 +8,17 @@ pub use fpu_precision::set_precision;
// round to 80 bits causing double rounding to happen when values are eventually represented as
// 32/64 bit float values. To overcome this, the FPU control word can be set so that the
// computations are performed in the desired precision.
//
// Note that normally, it is Undefined Behavior to alter the FPU control word while Rust code runs.
// The compiler assumes that the control word is always in its default state. However, in this
// particular case the semantics with the altered control word are actually *more faithful*
// to Rust semantics than the default -- arguably it is all the code that runs *outside* of the scope
// of a `set_precision` guard that is wrong.
// In other words, we are only using this to work around <https://github.com/rust-lang/rust/issues/114479>.
// Sometimes killing UB with UB actually works...
// (If this is used to set 32bit precision, there is still a risk that the compiler moves some 64bit
// operation into the scope of the `set_precision` guard. So it's not like this is totally sound.
// But it's not really any less sound than the default state of 80bit precision...)
#[cfg(all(target_arch = "x86", not(target_feature = "sse2")))]
mod fpu_precision {
use core::arch::asm;

View File

@ -51,6 +51,7 @@ impl Number {
/// There is an exception: disguised fast-path cases, where we can shift
/// powers-of-10 from the exponent to the significant digits.
pub fn try_fast_path<F: RawFloat>(&self) -> Option<F> {
// Here we need to work around <https://github.com/rust-lang/rust/issues/114479>.
// The fast path crucially depends on arithmetic being rounded to the correct number of bits
// without any intermediate rounding. On x86 (without SSE or SSE2) this requires the precision
// of the x87 FPU stack to be changed so that it directly rounds to 64/32 bit.