[llvm-branch-commits] [llvm] [AArch64] SLP can vectorize frem (PR #82488)

[Paul Walker via llvm-branch-commits]

================
@@ -869,6 +870,18 @@ TargetTransformInfo::getOperandInfo(const Value *V) {
   return {OpInfo, OpProps};
 }
 
+InstructionCost TargetTransformInfo::getVecLibCallCost(
+    const int OpCode, const TargetLibraryInfo *TLI, VectorType *VecTy,
+    TTI::TargetCostKind CostKind) {
+  Type *ScalarTy = VecTy->getScalarType();
+  LibFunc Func;
+  if (TLI->getLibFunc(OpCode, ScalarTy, Func) &&
+      TLI->isFunctionVectorizable(TLI->getName(Func), VecTy->getElementCount()))
----------------
paulwalker-arm wrote:

I think it's more subtle than this.  Sure there's some target specific behaviour but that is hidden behind TLI as it should be, and I have no problem passing TLI into a TTI cost function.  The problem with TTI is that it needs to give a different answer based on whether it is called before the ReplaceWithVecLib pass or after (or when ReplaceWithVecLib is never run).  I don't think TTI has access to such information? Not would I want this to be something all cost functions need to worry about.

Personally I'm happy with keeping this nuance outside of TTI but if we really want this captured within TTI then I think it's time to break FREM into its own cost function (i.e. implement `getFRemInstrCost`.  That way getArithmeticInstrCost can work as it does today and the new function can be documented to highlight it's assumption that if a TLI is passed in and a vector mapping is present then the return value is only valid based on it's assumption that vector FREM instructions will be transformed by a following transformation pass.  I prefer this to say, adding TLI to getArithmeticInstrCost, because I'd rather users of `getFRemInstrCost` to explicitly enter into this contract.


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