[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