[ConstantFold] fp_binop AnyConstant, undef --> NaN

With the updated LangRef ( D44216 / rL327138 ) in place, we can proceed with more constant folding.

I'm intentionally taking the conservative path here: no matter what the constant or the FMF, we can 
always fold to NaN. This is because the undef operand can be chosen as NaN, and in our simplified 
default FP env, nothing else happens - NaN just propagates to the result. If we find some way/need 
to propagate undef instead, that can be added subsequently.

The tests show that we always choose the same quiet NaN constant (0x7FF8000000000000 in IR text). 
There were suggestions to improve that with a 'NaN' string token or not always print a 64-bit hex 
value, but those are independent changes. We might also consider setting/propagating the payload of 
NaN constants as an enhancement.

Differential Revision: https://reviews.llvm.org/D44308

llvm-svn: 327208

1 files changed, 8 insertions, 2 deletions

diff --git a/llvm/lib/IR/ConstantFold.cpp b/llvm/lib/IR/ConstantFold.cpp
index f6ec12d..92d35a2 100644
--- a/llvm/lib/IR/ConstantFold.cpp
+++ b/llvm/lib/IR/ConstantFold.cpp
@@ -1012,8 +1012,14 @@ Constant *llvm::ConstantFoldBinaryInstruction(unsigned Opcode,
       // [any flop] undef, undef -> undef
       if (isa<UndefValue>(C1) && isa<UndefValue>(C2))
         return C1;
-      // TODO: Handle one undef operand and some other constant.
-      return nullptr;
+      // [any flop] C, undef -> NaN
+      // [any flop] undef, C -> NaN
+      // We could potentially specialize NaN/Inf constants vs. 'normal'
+      // constants (possibly differently depending on opcode and operand). This
+      // would allow returning undef sometimes. But it is always safe to fold to
+      // NaN because we can choose the undef operand as NaN, and any FP opcode
+      // with a NaN operand will propagate NaN.
+      return ConstantFP::getNaN(C1->getType());
     case Instruction::BinaryOpsEnd:
       llvm_unreachable("Invalid BinaryOp");
     }