[PATCH] D139074: Vectorization Of Conditional Statements Using BOSCC

Matt D. via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 18 16:15:03 PDT 2023


Matt added inline comments.


================
Comment at: llvm/lib/Analysis/VectorUtils.cpp:441
+  if (VF <= 4) {
+    // Create the intermedeate vector type cast if required
+    // i.e.  promote <4 x i1> to <4 x i8> type
----------------



================
Comment at: llvm/lib/Analysis/VectorUtils.cpp:442
+    // Create the intermedeate vector type cast if required
+    // i.e.  promote <4 x i1> to <4 x i8> type
+    Type *VecTy = FixedVectorType::get(Builder.getIntNTy(8), VF);
----------------
(Extremely minor / formatting: stray space replaced with a comma after `i.e.`)


================
Comment at: llvm/lib/Analysis/VectorUtils.cpp:457
+      // 1. SubVector Extract
+      // %vec.extract = shufflevector <128 x i1> %Vector, <128 x i1> %undef, <32
+      // x i32> Mask
----------------



================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:207
+static cl::opt<unsigned> BOSCCInstructionInBlockThreshold(
+    "boscc-instructions-in-threshold", cl::init(5), cl::Hidden,
+    cl::desc("The minimum instructions in a block required for boscc"));
----------------
I'm curious about the difference from AOCC here. Context: My understanding (from the EuroLLVM 2023) talk is that this has been already implemented in AOCC before. I'm wondering, were the cost model decisions / profitability analysis the same? I'm curious about it in the context of the (already resolved) ICE--is it possible that AOCC was able to avoid running into an ICE whereas this patch previously exposed a possibly missing precondition/assumption (could there be any more follow-on issues?)


================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:8167
+// BB.BOSCC.GUARD : This serves the purpose of guarding with right condition
+// BB.BOSCC.VEC : This is the vector block corrosponds to BB
+// BB.BOSCC.VEC.CONTINUE: Auxilary block to facilitate control flow
----------------
(Minor typo; tense): s/corrosponds/corresponds/


================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:8168
+// BB.BOSCC.VEC : This is the vector block corrosponds to BB
+// BB.BOSCC.VEC.CONTINUE: Auxilary block to facilitate control flow
+// BB.BOSCC.JOIN: Required for PHI generation for the live out from BB
----------------
(Minor typo) s/Auxilary/Auxiliary/


================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:8203
+    return false;
+  // If the instruction has usage across basic block
+  for (Use &U : I->uses()) {
----------------
(I presume we care about usage across more than one basic block in general?)


================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:9067
     // ingredients and fill a new VPBasicBlock.
+    // Init the BOSCC Planner and check the legal and profitablity
+    BOSCCBlockPlanner BOSCCPlanner(BB, VPBB, OrigLoop, DT, &TTI, Builder);
----------------



================
Comment at: llvm/lib/Transforms/Vectorize/VPlan.cpp:55
 
+extern cl::opt<bool> EnableBOSCCVectorization;
+
----------------
Is it intentional to have `EnableBOSCCVectorization` in the global namespace (outside of `namespace llvm`, cf. `EnableVPlanNativePath` a few lines above)?


================
Comment at: llvm/lib/Transforms/Vectorize/VPlan.h:2768
+
+  /// Mark VPlan indicating
+  void markPlanWithBOSCC() { HasBOSCCBlocks = true; }
----------------
This comment appears to be unfinished.


================
Comment at: llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp:1077
+// It will have 2 incoming values, first representing value from
+// vector block, and the second in undefined value when vector block
+// is not executed.
----------------
(update comment alone to reflect already correctly using `PoisonValue` in the code)


================
Comment at: llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp:1093
+//   %12 = phi <8 x i32> [ %SomeComputedValue, %if.then.boscc.vec.continue ],
+//                       [ undef, %if.then.boscc.guard ]
+void VPBOSCCLiveOutRecipe::execute(VPTransformState &State) {
----------------
(update comment alone to reflect already correctly using `PoisonValue` in the code)


================
Comment at: llvm/lib/Transforms/Vectorize/VPlanRecipes.cpp:1094
+//                       [ undef, %if.then.boscc.guard ]
+void VPBOSCCLiveOutRecipe::execute(VPTransformState &State) {
+  VPValue *ScalarLiveOut = getOperand(0);
----------------
I think this function could benefit from more comments explaining the logic--similarly to comments in `createVectorToScalarCast` in this patch (which are pretty good!)


================
Comment at: llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp:151
+    if (isa<VPBOSCCLiveOutRecipe>(*RecipeI)) {
+      RecipeI++;
+      continue;
----------------
(Coding style) Nit: Preincrement form `++RecipeI` is preferable (particularly for an iterator), https://llvm.org/docs/CodingStandards.html#prefer-preincrement



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139074



More information about the llvm-commits mailing list