From e2b89118bdc13d16d6cf68af3689ecaede279cda Mon Sep 17 00:00:00 2001 From: Hal Finkel Date: Wed, 4 May 2016 19:37:08 +0000 Subject: [ConstantFold] Don't try to strip fp -> int bitcasts to simplify icmps ConstantFold has logic to take icmp (bitcast x to y), null and strip the bitcast. This makes sense in general, but not if x has floating-point type. In this case, we'd need a fcmp, not an icmp, and the code will assert. We normally don't see this situation because we constant fold fp -> int bitcasts, however, we'll see it for bitcasts of ppc_fp128 -> i128. This is because that bitcast is Endian-dependent, and as a result, we don't simplify it in ConstantFold (we could, but no one has yet added the necessary logic). Regardless, ConstantFold should not depend on that canonicalization for correctness. llvm-svn: 268534 --- llvm/lib/IR/ConstantFold.cpp | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'llvm/lib/IR/ConstantFold.cpp') diff --git a/llvm/lib/IR/ConstantFold.cpp b/llvm/lib/IR/ConstantFold.cpp index 863b2c4bf41..a338d01a83d 100644 --- a/llvm/lib/IR/ConstantFold.cpp +++ b/llvm/lib/IR/ConstantFold.cpp @@ -1529,6 +1529,10 @@ static ICmpInst::Predicate evaluateICmpRelation(Constant *V1, Constant *V2, case Instruction::BitCast: case Instruction::ZExt: case Instruction::SExt: + // We can't evaluate floating point casts or truncations. + if (CE1Op0->getType()->isFloatingPointTy()) + break; + // If the cast is not actually changing bits, and the second operand is a // null pointer, do the comparison with the pre-casted value. if (V2->isNullValue() && -- cgit v1.2.3