================
@@ -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
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
