[llvm] [LV] Add select instruction to VPReplicateRecipe::computeCost (PR #186825)

David Sherwood via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 16 08:53:32 PDT 2026


https://github.com/david-arm created https://github.com/llvm/llvm-project/pull/186825

I've added the Instruction::Select opcode to the existing list of opcodes that call getCostForRecipeWithOpcode. There are currently 5 tests that ask for the cost of the select:

  Transforms/LoopVectorize/AArch64/widen-gep-all-indices-invariant.ll
  Transforms/LoopVectorize/first-order-recurrence-with-uniform-ops.ll
  Transforms/LoopVectorize/narrow-to-single-scalar.ll
  Transforms/LoopVectorize/replicate_fneg.ll
  Transforms/LoopVectorize/single-scalar-cast-minbw.ll

The fact they all pass with this change is hopefully proof enough that the costs are correct. However, in general I think we rarely execute VPReplicateRecipe::computeCost for instructions in the vector loop due to LoopVectorizationPlanner::precomputeCosts forcing us to use the legacy costs instead. This does help to stop the legacy/vplan cost model assert firing, but doesn't help with it's eventual removal. I intend to follow up with more PRs to remove these pre-computed costs because otherwise the replicate cost model will just end up being dead code.

>From c413334da4224ce47334043d9749f8bb47e81dda Mon Sep 17 00:00:00 2001
From: David Sherwood <david.sherwood at arm.com>
Date: Mon, 16 Mar 2026 15:51:09 +0000
Subject: [PATCH] [LV] Add select to VPReplicateRecipe::computeCost

I've added the Instruction::Select opcode to the existing list
of opcodes that call getCostForRecipeWithOpcode. There are
currently 5 tests that ask for the cost of the select:

  Transforms/LoopVectorize/AArch64/widen-gep-all-indices-invariant.ll
  Transforms/LoopVectorize/first-order-recurrence-with-uniform-ops.ll
  Transforms/LoopVectorize/narrow-to-single-scalar.ll
  Transforms/LoopVectorize/replicate_fneg.ll
  Transforms/LoopVectorize/single-scalar-cast-minbw.ll

The fact they all pass with this change is hopefully proof enough
that the costs are correct. However, in general I think we rarely
execute VPReplicateRecipe::computeCost for instructions in the
vector loop due to LoopVectorizationPlanner::precomputeCosts
forcing us to use the legacy costs instead. This does help to
stop the legacy/vplan cost model assert firing, but doesn't
help with it's eventual removal. I intend to follow up with more
PRs to remove these pre-computed costs because otherwise the
replicate cost model will just end up being dead code.
---
 llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp b/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
index 26183f15306f1..39a1159eb1264 100644
--- a/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
+++ b/llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp
@@ -3603,6 +3603,7 @@ InstructionCost VPReplicateRecipe::computeCost(ElementCount VF,
   case Instruction::UIToFP:
   case Instruction::Trunc:
   case Instruction::FPTrunc:
+  case Instruction::Select:
   case Instruction::AddrSpaceCast: {
     return getCostForRecipeWithOpcode(getOpcode(), ElementCount::getFixed(1),
                                       Ctx) *



More information about the llvm-commits mailing list