[llvm] [ARM]Adjust cost of muls in SMLAL patterns (PR #122713)

[Nashe Mncube via llvm-commits]

================
@@ -1458,16 +1458,62 @@ InstructionCost ARMTTIImpl::getArithmeticInstrCost(
   if (LooksLikeAFreeShift())
     return 0;
 
+  // When targets have both DSP and MVE we find that the
+  // the compiler will attempt to vectorize as well as using
+  // scalar SMLAL operations. This is in cases where we have
+  // the pattern ext(mul(ext(i16), ext(i16))) we find
+  // that generated codegen performs better when only using SMLAL scalar
+  // ops instead of trying to mix vector ops with SMLAL ops. We therefore
+  // check if a mul instruction is used in a SMLAL pattern.
+  auto MulInSMLALPattern = [&](const Instruction *I, unsigned Opcode,
+                               Type *Ty) -> bool {
+    if (!ST->hasDSP() || !ST->hasMVEIntegerOps())
+      return false;
+    if (!I)
+      return false;
+
+    if (Opcode != Instruction::Mul)
+      return false;
+
+    if (Ty->isVectorTy())
+      return false;
+
+    auto IsSExtInst = [](const Value *V) -> bool {
+      return (dyn_cast<SExtInst>(V)) ? true : false;
+    };
+
+    // We check the arguments of the function to see if they're extends
+    auto *BinOp = dyn_cast<BinaryOperator>(I);
+    if (!BinOp)
+      return false;
+    auto *Op0 = BinOp->getOperand(0);
+    auto *Op1 = BinOp->getOperand(1);
+    if (Op0 && Op1 && IsSExtInst(Op0) && IsSExtInst(Op1)) {
+      // In this case we're interested in an ext of an i16
+      if (!Op0->getType()->isIntegerTy(32) || !Op1->getType()->isIntegerTy(32))
+        return false;
+      // We need to check if this result will be further extended to i64
+      for (auto *U : I->users())
+        if (IsSExtInst(dyn_cast<Value>(U)))
+          return true;
----------------
nasherm wrote:

Done

https://github.com/llvm/llvm-project/pull/122713