Skip to content

Commit 78124a2

Browse files
committed
Fix fast path of float parsing on x87
The fast path of the float parser relies on the rounding to happen exactly and directly to the correct number of bits. On x87, instead, double rounding would occour as the FPU stack defaults to 80 bits of precision. This can be fixed by setting the precision of the FPU stack before performing the int to float conversion. This can be achieved by changing the value of the x87 control word. This is a somewhat common operation that is in fact performed whenever a float needs to be truncated to an integer, but it is undesirable to add its overhead for code that does not rely on x87 for computations (i.e. on non-x86 architectures, or x86 architectures which perform FPU computations on using SSE). Fixes `num::dec2flt::fast_path_correct` (on x87).
1 parent a581c82 commit 78124a2

File tree

2 files changed

+42
-7
lines changed

2 files changed

+42
-7
lines changed

src/libcore/lib.rs

+2
Original file line numberDiff line numberDiff line change
@@ -61,7 +61,9 @@
6161
#![cfg_attr(not(stage0), deny(warnings))]
6262

6363
#![feature(allow_internal_unstable)]
64+
#![feature(asm)]
6465
#![feature(associated_type_defaults)]
66+
#![feature(cfg_target_feature)]
6567
#![feature(concat_idents)]
6668
#![feature(const_fn)]
6769
#![feature(cfg_target_has_atomic)]

src/libcore/num/dec2flt/algorithm.rs

+40-7
Original file line numberDiff line numberDiff line change
@@ -32,19 +32,49 @@ fn power_of_ten(e: i16) -> Fp {
3232
Fp { f: sig, e: exp }
3333
}
3434

35+
#[cfg(any(not(target_arch="x86"), target_feature="sse2"))]
36+
mod fpu_precision {
37+
pub fn set_precision<T>() { }
38+
}
39+
40+
#[cfg(all(target_arch="x86", not(target_feature="sse2")))]
41+
mod fpu_precision {
42+
use mem::size_of;
43+
use ops::Drop;
44+
45+
pub struct FPUControlWord(u16);
46+
47+
fn set_cw(cw: u16) {
48+
unsafe { asm!("fldcw $0" :: "m" (cw)) :: "volatile" }
49+
}
50+
51+
pub fn set_precision<T>() -> FPUControlWord {
52+
let cw = 0u16;
53+
let cw_precision = match size_of::<T>() {
54+
4 => 0x0000, // 32 bits
55+
8 => 0x0200, // 64 bits
56+
_ => 0x0300, // default, 80 bits
57+
};
58+
unsafe { asm!("fnstcw $0" : "=*m" (&cw)) ::: "volatile" }
59+
set_cw((cw & 0xFCFF) | cw_precision);
60+
FPUControlWord(cw)
61+
}
62+
63+
impl Drop for FPUControlWord {
64+
fn drop(&mut self) {
65+
set_cw(self.0)
66+
}
67+
}
68+
}
69+
3570
/// The fast path of Bellerophon using machine-sized integers and floats.
3671
///
3772
/// This is extracted into a separate function so that it can be attempted before constructing
3873
/// a bignum.
3974
///
4075
/// The fast path crucially depends on arithmetic being correctly rounded, so on x86
41-
/// without SSE or SSE2 it will be **wrong** (as in, off by one ULP occasionally), because the x87
42-
/// FPU stack will round to 80 bit first before rounding to 64/32 bit. However, as such hardware
43-
/// is extremely rare nowadays and in fact all in-tree target triples assume an SSE2-capable
44-
/// microarchitecture, there is little incentive to deal with that. There's a test that will fail
45-
/// when SSE or SSE2 is disabled, so people building their own non-SSE copy will get a heads up.
46-
///
47-
/// FIXME: It would nevertheless be nice if we had a good way to detect and deal with x87.
76+
/// without SSE or SSE2 it requires the precision of the x87 FPU stack to be changed
77+
/// so that it directly rounds to 64/32 bit.
4878
pub fn fast_path<T: RawFloat>(integral: &[u8], fractional: &[u8], e: i64) -> Option<T> {
4979
let num_digits = integral.len() + fractional.len();
5080
// log_10(f64::max_sig) ~ 15.95. We compare the exact value to max_sig near the end,
@@ -60,6 +90,9 @@ pub fn fast_path<T: RawFloat>(integral: &[u8], fractional: &[u8], e: i64) -> Opt
6090
if f > T::max_sig() {
6191
return None;
6292
}
93+
94+
let _cw = fpu_precision::set_precision::<T>();
95+
6396
// The case e < 0 cannot be folded into the other branch. Negative powers result in
6497
// a repeating fractional part in binary, which are rounded, which causes real
6598
// (and occasioally quite significant!) errors in the final result.

0 commit comments

Comments
 (0)