[PATCH] D147783: [VPlan] Add stride->constant VPlan mapping at construction.

Mon May 29 00:50:37 PDT 2023

Ayal added inline comments.

================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:8897
+    else
+      Plan->addVPValue(StrideV, new VPValue(CI));
+  }
----------------
This is essentially short-circuiting an RAUW. When VPlan will take care of the check for unit stride, only users inside the vector loop (, its preheader, middle block, and epilog vector loop?) will need to be replaced, the compare (and scalar loop) should continue to use the original stride of-course.
Worth setting it up as an RAUW of original stride VPValue with "1" VPValue, after all users of the former have been set up?

================
Comment at: llvm/test/Transforms/LoopVectorize/RISCV/strided-accesses.ll:236
 ; NOSTRIDED-NEXT:    [[TMP5:%.*]] = add i64 [[INDEX]], 0
-; NOSTRIDED-NEXT:    [[TMP6:%.*]] = mul nuw nsw i64 [[TMP5]], [[STRIDE]]
+; NOSTRIDED-NEXT:    [[TMP6:%.*]] = mul nuw nsw i64 [[TMP5]], 1
 ; NOSTRIDED-NEXT:    [[TMP7:%.*]] = getelementptr i32, ptr [[P:%.*]], i64 [[TMP6]]
----------------
reames wrote:
> Completely unrelated to this, but it looks like we've got opportunity to fold these multiplies now.  Is this coming from an IRBuilder or a SCEVExpander?  If the former, we may just need to adjust the folder at construction.  (Assuming that eager folding doesn't interact badly with something inside LV/FPlan - which you'll have a much better idea than I do.)
Yes, there's room for some constant folding here, and also the add 0. Would be good to ensure LV's cost model for such predicated unit stride accesses is accurate, and potentially apply these foldings in VPlan, independent of foldings at IR generation.

================
Comment at: llvm/test/Transforms/LoopVectorize/RISCV/strided-accesses.ll:316
 ; NOSTRIDED-NEXT:    [[N_VEC:%.*]] = sub i64 1024, [[N_MOD_VF]]
 ; NOSTRIDED-NEXT:    [[IND_END:%.*]] = mul i64 [[N_VEC]], [[STRIDE]]
 ; NOSTRIDED-NEXT:    br label [[VECTOR_BODY:%.*]]
----------------
nit: such appearances of STRIDE in vector.ph should also be removed once Induction Resume Values are created via recipes, right?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147783/new/

https://reviews.llvm.org/D147783