[Reassociate][NFC] Consistent checking if FastMathFlags are suitable

[wristow]

Summary

In D129523, it was noted by @spatel 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.

[spatel]

Thanks! LGTM

[wristow]

Thanks Sanjay!

llvm/lib/Transforms/Scalar/Reassociate.cpp

XorOpnd::XorOpnd(Value *V) {
   isOr = true;
 }
 
 /// Return true if I is an instruction with the FastMathFlags that are needed
 /// for general reassociation set.  This is not the same as testing
 /// 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();
 }
 
 /// Return true if V is an instruction of the specified opcode and if it
 /// only has one use.
 static BinaryOperator *isReassociableOp(Value *V, unsigned Opcode) {
   auto *I = dyn_cast<Instruction>(V);
   if (I && I->hasOneUse() && I->getOpcode() == Opcode)
for (unsigned i = 0; ; ++i) {
     // hard (finding the mimimal number of multiplications needed to realize a
     // multiplication expression is NP-complete).  Whatever the reason, smart or
     // stupid, create a new node if there are none left.
     BinaryOperator *NewOp;
     if (NodesToRewrite.empty()) {
       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();
     }
 
     LLVM_DEBUG(dbgs() << "RA: " << *Op << '\n');
     Op->setOperand(0, NewOp);
     LLVM_DEBUG(dbgs() << "TO: " << *Op << '\n');
if (I->isCommutative())
     canonicalizeOperands(I);
 
   // Canonicalize negative constants out of expressions.
   if (Instruction *Res = canonicalizeNegFPConstants(I))
     I = Res;
 
   // 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
   // original order of evaluation for short-circuited comparisons that
   // SimplifyCFG has folded to AND/OR expressions.  If the expression
   // is not further optimized, it is likely to be transformed back to a
   // short-circuited form for code gen, and the source order may have been
   // optimized for the most likely conditions.