[Reassociate][NFC] Consistent checking for FastMathFlags suitability

In D129523, it was noted that the approach to check whether a value can
have FastMathFlags was done in different ways, and they should be made
consistent.  This patch makes minor changes to fix that.

Reviewed By: spatel

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

diff --git a/llvm/lib/Transforms/Scalar/Reassociate.cpp b/llvm/lib/Transforms/Scalar/Reassociate.cpp
index 240fb5e60687db8eb7a9face11e0c572bd7b5db9..53575f55c6fbd12bb67fe65b08f4aa0f2b986f8f 100644 (file)
--- a/llvm/lib/Transforms/Scalar/Reassociate.cpp
+++ b/llvm/lib/Transforms/Scalar/Reassociate.cpp
@@ -147,7 +147,7 @@ XorOpnd::XorOpnd(Value *V) {
 /// Instruction::isAssociative() because it includes operations like fsub.
 /// (This routine is only intended to be called for floating-point operations.)
 static bool hasFPAssociativeFlags(Instruction *I) {
-  assert(I && I->getType()->isFPOrFPVectorTy() && "Should only check FP ops");
+  assert(I && isa<FPMathOperator>(I) && "Should only check FP ops");
   return I->hasAllowReassoc() && I->hasNoSignedZeros();
 }
 
@@ -778,7 +778,7 @@ void ReassociatePass::RewriteExprTree(BinaryOperator *I,
       Constant *Undef = UndefValue::get(I->getType());
       NewOp = BinaryOperator::Create(Instruction::BinaryOps(Opcode),
                                      Undef, Undef, "", I);
-      if (NewOp->getType()->isFPOrFPVectorTy())
+      if (isa<FPMathOperator>(NewOp))
         NewOp->setFastMathFlags(I->getFastMathFlags());
     } else {
       NewOp = NodesToRewrite.pop_back_val();
@@ -2227,7 +2227,7 @@ void ReassociatePass::OptimizeInst(Instruction *I) {
 
   // Don't optimize floating-point instructions unless they have the
   // appropriate FastMathFlags for reassociation enabled.
-  if (I->getType()->isFPOrFPVectorTy() && !hasFPAssociativeFlags(I))
+  if (isa<FPMathOperator>(I) && !hasFPAssociativeFlags(I))
     return;
 
   // Do not reassociate boolean (i1) expressions.  We want to preserve the