[SCEV] isHighCostExpansionHelper(): use correct TTI hooks

[lebedev.ri]

Summary

Cost modelling strikes again.
In PR44668 https://bugs.llvm.org/show_bug.cgi?id=44668 patch series,
i've made the same mistake of always using generic getOperationCost()
that i missed in reviewing D73480/D74495 which was later fixed
in 62dd44d76da9aa596fb199bda8b1e8768bb41033.

We should be using more specific hooks instead - getCastInstrCost(),
getArithmeticInstrCost(), getCmpSelInstrCost().

Evidently, this does not have an effect on the existing testcases,
with unchanged default cost budget. But if it *does* have an effect
on some target, we'll have to segregate tests that use this function
per-target, much like we already do with other TTI-aware transform tests.

There's also an issue that @samparker has brought up in post-commit-review:

In D73501#1905171, @samparker wrote:

Hi,
Did you get performance numbers for these patches? We track the performance
of our (Arm) open source DSP library and the cost model fixes were generally
a notable improvement, so many thanks for that! But the final patch
for rewriting exit values has generally been bad, especially considering
the gains from the modelling improvements. I need to look into it further,
but on my current test case I'm seeing +30% increase in stack accesses
with a similar decrease in performance.
I'm just wondering if you observed any negative effects yourself?

I don't know if this addresses that, or we need D66450 for that.

[reames]

LGTM.

Though, I'll comment that this interface is broken. If the generically named function doesn't do the same thing as the specifically named version given the same arguments, that's a bug in the API design. The only one of these which is defensible is the select changes. The LGTM is because this is a generic problem, and I don't want to block progress in this specific area on the generic fix.

[samparker]

Agreed that it's broken, but it looks like SCEV expander is the only place that this API is/was used. Can we now remove getOperationCost?

[lebedev.ri]

Thank you for the review.

[reames]

In D75908#1916313, @samparker wrote:

Agreed that it's broken, but it looks like SCEV expander is the only place that this API is/was used. Can we now remove getOperationCost?

If the code is dead, sure. That's a great way to fix broken code. :)

[lebedev.ri]

In D75908#1919587, @reames wrote:

In D75908#1916313, @samparker wrote:

Agreed that it's broken, but it looks like SCEV expander is the only place that this API is/was used. Can we now remove getOperationCost?

If the code is dead, sure. That's a great way to fix broken code. :)

+1. If it's really not used let's drop it. It was mis-used twice already in just last month or so.

[samparker]

Then I'll get a patch together, hopefully then we can transition TTI away from the under-implemented parts of the API.

[samparker]

Removal is in D76124.

llvm/lib/Analysis/ScalarEvolutionExpander.cpp

if (auto *CastExpr = dyn_cast<SCEVCastExpr>(S)) {
     case scSignExtend:
       Opcode = Instruction::SExt;
       break;
     default:
       llvm_unreachable("There are no other cast types.");
     }
     const SCEV *Op = CastExpr->getOperand();
     BudgetRemaining -=
-        TTI.getOperationCost(Opcode, S->getType(), Op->getType());
+        TTI.getCastInstrCost(Opcode, S->getType(), Op->getType());
     return isHighCostExpansionHelper(Op, L, At, BudgetRemaining, TTI,
                                      Processed);
   }
 
 
   if (auto *UDivExpr = dyn_cast<SCEVUDivExpr>(S)) {
     // If the divisor is a power of two count this as a logical right-shift.
     if (auto *SC = dyn_cast<SCEVConstant>(UDivExpr->getRHS())) {
       if (SC->getAPInt().isPowerOf2()) {
         BudgetRemaining -=
-            TTI.getOperationCost(Instruction::LShr, S->getType());
+            TTI.getArithmeticInstrCost(Instruction::LShr, S->getType());
         // Note that we don't count the cost of RHS, because it is a constant,
         // and we consider those to be free. But if that changes, we would need
         // to log2() it first before calling isHighCostExpansionHelper().
         return isHighCostExpansionHelper(UDivExpr->getLHS(), L, At,
                                          BudgetRemaining, TTI, Processed);
       }
     }
 
     // UDivExpr is very likely a UDiv that ScalarEvolution's HowFarToZero or
     // HowManyLessThans produced to compute a precise expression, rather than a
     // UDiv from the user's code. If we can't find a UDiv in the code with some
     // simple searching, we need to account for it's cost.
 
     // At the beginning of this function we already tried to find existing
     // value for plain 'S'. Now try to lookup 'S + 1' since it is common
     // pattern involving division. This is just a simple search heuristic.
     if (getRelatedExistingExpansion(
             SE.getAddExpr(S, SE.getConstant(S->getType(), 1)), &At, L))
       return false; // Consider it to be free.
 
     // Need to count the cost of this UDiv.
-    BudgetRemaining -= TTI.getOperationCost(Instruction::UDiv, S->getType());
+    BudgetRemaining -=
+        TTI.getArithmeticInstrCost(Instruction::UDiv, S->getType());
     return isHighCostExpansionHelper(UDivExpr->getLHS(), L, At, BudgetRemaining,
                                      TTI, Processed) ||
            isHighCostExpansionHelper(UDivExpr->getRHS(), L, At, BudgetRemaining,
                                      TTI, Processed);
   }
 
   if (const auto *NAry = dyn_cast<SCEVAddRecExpr>(S)) {
     Type *OpType = NAry->getType();
 
     assert(NAry->getNumOperands() >= 2 &&
            "Polynomial should be at least linear");
 
-    int AddCost = TTI.getOperationCost(Instruction::Add, OpType);
-    int MulCost = TTI.getOperationCost(Instruction::Mul, OpType);
+    int AddCost = TTI.getArithmeticInstrCost(Instruction::Add, OpType);
+    int MulCost = TTI.getArithmeticInstrCost(Instruction::Mul, OpType);
 
     // In this polynominal, we may have some zero operands, and we shouldn't
     // really charge for those. So how many non-zero coeffients are there?
     int NumTerms = llvm::count_if(NAry->operands(),
                                   [](const SCEV *S) { return !S->isZero(); });
     assert(NumTerms >= 1 && "Polynominal should have at least one term.");
     assert(!(*std::prev(NAry->operands().end()))->isZero() &&
            "Last operand should not be zero");
bool SCEVExpander::isHighCostExpansionHelper(
   }
 
   if (const SCEVNAryExpr *NAry = dyn_cast<SCEVNAryExpr>(S)) {
     Type *OpType = NAry->getType();
 
     int PairCost;
     switch (S->getSCEVType()) {
     case scAddExpr:
-      PairCost = TTI.getOperationCost(Instruction::Add, OpType);
+      PairCost = TTI.getArithmeticInstrCost(Instruction::Add, OpType);
       break;
     case scMulExpr:
       // TODO: this is a very pessimistic cost modelling for Mul,
       // because of Bin Pow algorithm actually used by the expander,
       // see SCEVExpander::visitMulExpr(), ExpandOpBinPowN().
-      PairCost = TTI.getOperationCost(Instruction::Mul, OpType);
+      PairCost = TTI.getArithmeticInstrCost(Instruction::Mul, OpType);
       break;
     case scSMaxExpr:
     case scUMaxExpr:
     case scSMinExpr:
     case scUMinExpr:
-      PairCost = TTI.getOperationCost(Instruction::ICmp, OpType) +
-                 TTI.getOperationCost(Instruction::Select, OpType);
+      PairCost = TTI.getCmpSelInstrCost(Instruction::ICmp, OpType,
+                                        CmpInst::makeCmpResultType(OpType)) +
+                 TTI.getCmpSelInstrCost(Instruction::Select, OpType,
+                                        CmpInst::makeCmpResultType(OpType));
       break;
     default:
       llvm_unreachable("There are no other variants here.");
     }
 
     assert(NAry->getNumOperands() > 1 &&
            "Nary expr should have more than 1 operand.");
     for (const SCEV *Op : NAry->operands()) {