[ConstantFolding] Disable constant folding for bitcasts to x86_fp80

[craig.topper]

Summary

80-bit floating point does not have an implicit hidden bit like single and double precision. If this bit is not set we can end up with various weird encodings like pseudo-denormals, pseudo-infinities, and unnormals. The APFloat conversion from APInt turns all of these things into a NAN and loses the original exponent from incoming bit representation. This means if the APFloat gets turned back into an APInt it might not be exactly the original value.

This patch disables the constant folding to avoid hitting this condition. We could maybe be smarter and look at the value we're going to convert and make sure its safe, but that would likely require a new APFloat interface to find that out.

Fixes PR44188. I can put together a test case based on that PR, but wanted to get an opinion on whether this patch was the right thing to do.

[efriedma]

Is this really the only place where we fold fp80 bitcasts? I guess it might be.

Would it make sense to allow encoding these non-canonical values into an APFloat? (Still treating it as a NaN, but keeping around enough information to reconstitute it if bitcastToAPInt is called.) If we don't think that's worthwhile, this seems like the right approach.

We could maybe be smarter and look at the value we're going to convert and make sure its safe

I'm a little concerned this might show up in more cases than you expect, where we end up with a bitcast in code that isn't explicitly reintepreting floats. For example, in code using C unions.

[craig.topper]

I was looking into trying to see if we could store this in APFloat. And I just noticed that we mark pseudonan, pseudoinfinity, and unnformals all as fcnan, and copy their original significand from the apint. I believe since the integer bit was 0, this makes apfloat encode them as a pseudonan. Then I think arithmetic operations with one of these as an operand will propagate the pseudonan. Should we have forced the integer bit of the significand when we created it to make it a true nan?

[efriedma]

To match x87 semantics, arithmetic on a pseudonan should trigger an exception and produce a quiet NaN. This is similar to an SNaN. (Not sure if we currently handle SNaNs correctly, though.)

llvm/lib/IR/ConstantFold.cpp

static Constant *FoldBitCast(Constant *V, Type *DestTy) {
   // Handle integral constant input.
   if (ConstantInt *CI = dyn_cast<ConstantInt>(V)) {
     if (DestTy->isIntegerTy())
       // Integral -> Integral. This is a no-op because the bit widths must
       // be the same. Consequently, we just fold to V.
       return V;
 
     // See note below regarding the PPC_FP128 restriction.
-    if (DestTy->isFloatingPointTy() && !DestTy->isPPC_FP128Ty())
+    // Also disable for x86_fp80 to avoid turning unnormals, a pseudo-denormals
+    // or pseudo-infinities into a nan which we can't convert back to the
+    // original value if it gets casted back to integer.
+    // FIXME: Can we preserve this information in APFloat?
+    if (DestTy->isFloatingPointTy() && !DestTy->isPPC_FP128Ty() &&
+        !DestTy->isX86_FP80Ty())
       return ConstantFP::get(DestTy->getContext(),
                              APFloat(DestTy->getFltSemantics(),
                                      CI->getValue()));
 
     // Otherwise, can't fold this (vector?)
     return nullptr;
   }
 

llvm/test/Transforms/InstCombine/X86/2009-03-23-i80-fp80.ll

 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
 ; RUN: opt < %s -instcombine -S | FileCheck %s
 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-v64:64:64-v128:128:128-a0:0:64-f80:128:128"
 target triple = "i686-apple-darwin9"
 
 define i80 @from() {
 ; CHECK-LABEL: @from(
 ; CHECK-NEXT:    ret i80 302245289961712575840256
 ;
   %tmp = bitcast x86_fp80 0xK4000C000000000000000 to i80
   ret i80 %tmp
 }
 
 define x86_fp80 @to() {
 ; CHECK-LABEL: @to(
-; CHECK-NEXT:    ret x86_fp80 0xK40018000000000000000
+; CHECK-NEXT:    ret x86_fp80 bitcast (i80 302259125019767858003968 to x86_fp80)
 ;
   %tmp = bitcast i80 302259125019767858003968 to x86_fp80
   ret x86_fp80 %tmp
 }