[llvm] [LV] Add initial cost model for VPScalarIVSteps (PR #203347)
Paul Walker via llvm-commits
llvm-commits at lists.llvm.org
Fri Jun 12 08:36:45 PDT 2026
================
@@ -424,75 +424,48 @@ define i32 @load_from_pointer_induction(ptr %start, ptr %end) {
; CHECK-NEXT: [[UMAX:%.*]] = call i64 @llvm.umax.i64(i64 [[END1]], i64 [[START2]])
; CHECK-NEXT: [[TMP0:%.*]] = add i64 [[UMAX]], 1
; CHECK-NEXT: [[TMP1:%.*]] = sub i64 [[TMP0]], [[START2]]
-; CHECK-NEXT: [[MIN_ITERS_CHECK:%.*]] = icmp ult i64 [[TMP1]], 8
+; CHECK-NEXT: [[MIN_ITERS_CHECK:%.*]] = icmp ult i64 [[TMP1]], 2
; CHECK-NEXT: br i1 [[MIN_ITERS_CHECK]], label %[[SCALAR_PH:.*]], label %[[VECTOR_PH:.*]]
; CHECK: [[VECTOR_PH]]:
-; CHECK-NEXT: [[N_MOD_VF:%.*]] = urem i64 [[TMP1]], 8
+; CHECK-NEXT: [[N_MOD_VF:%.*]] = urem i64 [[TMP1]], 2
; CHECK-NEXT: [[N_VEC:%.*]] = sub i64 [[TMP1]], [[N_MOD_VF]]
; CHECK-NEXT: [[TMP2:%.*]] = getelementptr i8, ptr [[START]], i64 [[N_VEC]]
; CHECK-NEXT: br label %[[VECTOR_BODY:.*]]
; CHECK: [[VECTOR_BODY]]:
; CHECK-NEXT: [[INDEX:%.*]] = phi i64 [ 0, %[[VECTOR_PH]] ], [ [[INDEX_NEXT:%.*]], %[[VECTOR_BODY]] ]
-; CHECK-NEXT: [[VEC_PHI:%.*]] = phi <4 x i32> [ zeroinitializer, %[[VECTOR_PH]] ], [ [[TMP28:%.*]], %[[VECTOR_BODY]] ]
-; CHECK-NEXT: [[VEC_PHI3:%.*]] = phi <4 x i32> [ zeroinitializer, %[[VECTOR_PH]] ], [ [[TMP29:%.*]], %[[VECTOR_BODY]] ]
+; CHECK-NEXT: [[VEC_PHI:%.*]] = phi i32 [ 0, %[[VECTOR_PH]] ], [ [[TMP8:%.*]], %[[VECTOR_BODY]] ]
+; CHECK-NEXT: [[VEC_PHI3:%.*]] = phi i32 [ 0, %[[VECTOR_PH]] ], [ [[TMP9:%.*]], %[[VECTOR_BODY]] ]
; CHECK-NEXT: [[TMP3:%.*]] = add i64 [[INDEX]], 1
-; CHECK-NEXT: [[TMP4:%.*]] = add i64 [[INDEX]], 2
-; CHECK-NEXT: [[TMP5:%.*]] = add i64 [[INDEX]], 3
-; CHECK-NEXT: [[TMP6:%.*]] = add i64 [[INDEX]], 4
-; CHECK-NEXT: [[TMP7:%.*]] = add i64 [[INDEX]], 5
-; CHECK-NEXT: [[TMP8:%.*]] = add i64 [[INDEX]], 6
-; CHECK-NEXT: [[TMP9:%.*]] = add i64 [[INDEX]], 7
----------------
paulwalker-arm wrote:
I don't mean to be a pain here but this looks to be the common idiom whereby the scalarised IV step is an offset to a load. While the new implementation of VPScalarIVStepsRecipe::computeCost looks sound I wonder if real world use cases will introduce double counting in the form of these adds and their use in the following GEPs.
I'm worried this sort of addressing is what loop-strength-reduce will rewrite and effectively remove the adds and so ultimately they cost nothing. For example:
````
y[i] = add x, ConstantOffsets[i] <---- 100 instances
getelementptr base, y[i] <---- 100 instances
becomes
y = add base, x
getelementptr y, ConstantOffsets[i] <---- 100 instances
````
https://github.com/llvm/llvm-project/pull/203347
More information about the llvm-commits
mailing list