[llvm] [VPlan] Extend getSCEVForVPV, use to compute VPReplicateRecipe cost. (PR #161276)

Florian Hahn via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 3 06:08:26 PDT 2025


================
@@ -3071,23 +3071,24 @@ bool VPReplicateRecipe::shouldPack() const {
 
 /// Returns true if \p Ptr is a pointer computation for which the legacy cost
 /// model computes a SCEV expression when computing the address cost.
-static bool shouldUseAddressAccessSCEV(const VPValue *Ptr) {
+static const SCEV *getAddressAccessSCEV(const VPValue *Ptr, ScalarEvolution &SE,
+                                        const Loop *L) {
   auto *PtrR = Ptr->getDefiningRecipe();
   if (!PtrR || !((isa<VPReplicateRecipe>(PtrR) &&
                   cast<VPReplicateRecipe>(PtrR)->getOpcode() ==
                       Instruction::GetElementPtr) ||
                  isa<VPWidenGEPRecipe>(PtrR)))
-    return false;
+    return nullptr;
 
   // We are looking for a GEP where all indices are either loop invariant or
   // inductions.
   for (VPValue *Opd : drop_begin(PtrR->operands())) {
     if (!Opd->isDefinedOutsideLoopRegions() &&
         !isa<VPScalarIVStepsRecipe, VPWidenIntOrFpInductionRecipe>(Opd))
-      return false;
+      return nullptr;
----------------
fhahn wrote:

nullptr is returned if we should not construct a SCEV expression, and SCEVCouldNotCompute is returned due to missing cases in `getSCEVExprForVPValue`. The reason to distinguish between them is that for the `nullptr` case we want to proceed with VPlan-based cost computation as previously, while if it is SCEVCouldNotCompute there would be a difference to legacy, so we fall back to it until `getSCEVExprForVPValue` is complete.

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


More information about the llvm-commits mailing list