Be more precise about which conversions of NaNs
authorDale Johannesen <dalej@apple.com>
Mon, 6 Oct 2008 22:59:10 +0000 (22:59 +0000)
committerDale Johannesen <dalej@apple.com>
Mon, 6 Oct 2008 22:59:10 +0000 (22:59 +0000)
are Inexact.  (These are not Inexact as defined
by IEEE754, but that seems like a reasonable way
to abstract what happens:  information is lost.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57218 91177308-0d34-0410-b5e6-96231b3b80d8

lib/Support/APFloat.cpp
test/CodeGen/X86/2008-10-06-x87ld-nan-1.ll [new file with mode: 0644]
test/CodeGen/X86/2008-10-06-x87ld-nan-2.ll [new file with mode: 0644]

index 3e37d796b41e9ddc1bc23e784a3a6f8bbe87eff0..b93f1d109a02df01ab0d29410fdccf237de9a1a2 100644 (file)
@@ -1721,17 +1721,32 @@ APFloat::convert(const fltSemantics &toSemantics,
   } else if (category == fcNaN) {
     int shift = toSemantics.precision - semantics->precision;
     // Do this now so significandParts gets the right answer
+    const fltSemantics *oldSemantics = semantics;
     semantics = &toSemantics;
+    fs = opOK;
     // No normalization here, just truncate
     if (shift>0)
       APInt::tcShiftLeft(significandParts(), newPartCount, shift);
-    else if (shift < 0)
-      APInt::tcShiftRight(significandParts(), newPartCount, -shift);
+    else if (shift < 0) {
+      unsigned ushift = -shift;
+      // We mark this as Inexact if we are losing information.  This happens
+      // if are shifting out something other than 0s, or if the x87 long
+      // double input did not have its integer bit set (pseudo-NaN), or if the
+      // x87 long double input did not have its QNan bit set (because the x87
+      // hardware sets this bit when converting a lower-precision NaN to
+      // x87 long double).
+      if (APInt::tcLSB(significandParts(), newPartCount) < ushift)
+        fs = opInexact;
+      if (oldSemantics == &APFloat::x87DoubleExtended && 
+          (!(*significandParts() & 0x8000000000000000ULL) ||
+           !(*significandParts() & 0x4000000000000000ULL)))
+        fs = opInexact;
+      APInt::tcShiftRight(significandParts(), newPartCount, ushift);
+    }
     // gcc forces the Quiet bit on, which means (float)(double)(float_sNan)
     // does not give you back the same bits.  This is dubious, and we
     // don't currently do it.  You're really supposed to get
     // an invalid operation signal at runtime, but nobody does that.
-    fs = opOK;
   } else {
     semantics = &toSemantics;
     fs = opOK;
diff --git a/test/CodeGen/X86/2008-10-06-x87ld-nan-1.ll b/test/CodeGen/X86/2008-10-06-x87ld-nan-1.ll
new file mode 100644 (file)
index 0000000..837aad5
--- /dev/null
@@ -0,0 +1,13 @@
+; ModuleID = 'nan.bc'
+target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-f80:32:32-v64:64:64-v128:128:128-a0:0:64"
+target triple = "i686-apple-darwin8"
+; RUN: llvm-as < %s | llc -march=x86 -mattr=-sse2,-sse3,-sse | grep fldl
+; This NaN should be shortened to a double (not a float).
+
+declare x86_stdcallcc void @_D3nan5printFeZv(x86_fp80 %f)
+
+define i32 @main() {
+entry_nan.main:
+  call x86_stdcallcc void @_D3nan5printFeZv(x86_fp80 0xK7FFFC001234000000800)
+  ret i32 0
+}
diff --git a/test/CodeGen/X86/2008-10-06-x87ld-nan-2.ll b/test/CodeGen/X86/2008-10-06-x87ld-nan-2.ll
new file mode 100644 (file)
index 0000000..d2e9b45
--- /dev/null
@@ -0,0 +1,18 @@
+; ModuleID = 'nan.bc'
+target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-f80:32:32-v64:64:64-v128:128:128-a0:0:64"
+target triple = "i686-apple-darwin8"
+; RUN: llvm-as < %s | llc -march=x86 -mattr=-sse2,-sse3,-sse | grep fldt | count 3
+; it is not safe to shorten any of these NaNs.
+
+declare x86_stdcallcc void @_D3nan5printFeZv(x86_fp80 %f)
+
+@_D3nan4rvale = global x86_fp80 0xK7FFF8001234000000000   ; <x86_fp80*> [#uses=1]
+
+define i32 @main() {
+entry_nan.main:
+  %tmp = load x86_fp80* @_D3nan4rvale   ; <x86_fp80> [#uses=1]
+  call x86_stdcallcc void @_D3nan5printFeZv(x86_fp80 %tmp)
+  call x86_stdcallcc void @_D3nan5printFeZv(x86_fp80 0xK7FFF8001234000000000)
+  call x86_stdcallcc void @_D3nan5printFeZv(x86_fp80 0xK7FFFC001234000000400)
+  ret i32 0
+}