[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