[PATCH] D157039: [VPlan] Add VPlan::hasTailFolded.

[Ayal Zaks via Phabricator via llvm-commits]

Ayal added a comment.

> Alternatively we could also add a flag to the VPlan.

Raising thoughts of other potential alternatives.



================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:3917
   // be predicated, and does not need to be handled here.
-  if (Cost->foldTailByMasking() && !PhiR->isInLoop()) {
+  if (PhiR->getParent()->getPlan()->hasTailFolded() && !PhiR->isInLoop()) {
     for (unsigned Part = 0; Part < UF; ++Part) {
----------------
Could recipes be set initially such that they generate code as needed, rather than (figuring out if tail was folded in order to) fix it here? This seems to require (a) setting FMF of Sel's recipe, (b) optionally rewiring a header phi recipe to Sel's recipe, (c) RAUW of LoopExitInstDef with Sel's recipe, rather than State.reset().


================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:9259
   // dedicated latch block.
-  if (CM.foldTailByMasking()) {
+  if (Plan->hasTailFolded()) {
     Builder.setInsertPoint(LatchVPBB, LatchVPBB->begin());
----------------
Here, during VPlan construction after header mask was proactively created (depending on D157037), it would be easy/easier to ask RecipeBuilder if the mask cached for the header block is null? Namely, check if `Cond` below is null.


================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:9271
              "reduction recipe must be defined before latch");
       Builder.createNaryOp(Instruction::Select, {Cond, Red, PhiR});
     }
----------------
Set the FMF of the select recipe upon creation here, rather than fixing its generated IR in fixReduction()?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157039