[llvm] [VPlan] First step towards VPlan cost modeling (LegacyCM in CostCtx) (PR #92555)
via llvm-commits
llvm-commits at lists.llvm.org
Tue May 28 02:36:37 PDT 2024
================
@@ -7396,6 +7397,118 @@ LoopVectorizationPlanner::plan(ElementCount UserVF, unsigned UserIC) {
return VF;
}
+InstructionCost VPCostContext::getLegacyCost(Instruction *UI, ElementCount VF) {
+ return CM.getInstructionCost(UI, VF).first;
+}
+
+bool VPCostContext::skipForCostComputation(Instruction *UI) const {
+ return CM.VecValuesToIgnore.contains(UI) || SkipCostComputation.contains(UI);
+}
+
+InstructionCost LoopVectorizationPlanner::computeCost(VPlan &Plan,
+ ElementCount VF) const {
+ InstructionCost Cost = 0;
+ LLVMContext &Ctx = OrigLoop->getHeader()->getContext();
+ VPCostContext CostCtx(CM.TTI, Legal->getWidestInductionType(), Ctx, CM);
+
+ // Cost modeling for inductions is inaccurate in the legacy cost model
+ // compared to the recipes that are generated. To match here initially during
+ // VPlan cost model bring up directly use the induction costs from the legacy
+ // cost model and skip induction recipes. Note that we do this as
+ // pre-processing; the VPlan may not have any recipes associated with the
+ // original induction increment instruction.
----------------
ayalz wrote:
OK, worth clarifying in the comment?
If original induction increment instructions do have recipes, is this pre-processing needed, in this preliminary version where recipe costs default to the CM cost of their underlying instructions? Perhaps to retain debug dumps.
Instructions associated with in-loop reductions do need to be pre-processed in order to take their getReductionPatternCost() rather than their getInstructionCost().
https://github.com/llvm/llvm-project/pull/92555
More information about the llvm-commits
mailing list