[VPlan] Verify dominance for incoming values of phi-like recipes. by fhahn · Pull Request #124838 · llvm/llvm-project

fhahn · 2025-01-28T21:10:26Z

Update the verifier to verify dominance for incoming values for phi-like recipes. The defining recipe must dominate the incoming block for the incoming value.

Builds on top of #138472 to retrieve incoming values & corresponding blocks for phi-like recipes.

llvmbot · 2025-01-28T21:11:01Z

@llvm/pr-subscribers-vectorizers

Author: Florian Hahn (fhahn)

Changes

Update the verifier to verify dominance for incoming values for phi-like recipes. The defining recipe must dominate the incoming block for the incoming value.

There are 4 different cases to consider when retrieving the incoming block:

VPIRInstructions wrapping phis: the incoming block from the blocks predecessors has the same index as the incoming value operand.
VPHeaderPhiRecipes, VPWidenPhi used in header: there's no predecessors; if the incoming value is the start value use the predecessor of the containing region, otherwise the exiting block of the region
1 predecessor: Must be a VPWidenPHI used as LCSSA phi; use the predecessor
2 predecessors: must be a VPPredInstPhiRecipe, use the second predecessor.

Full diff: https://github.com/llvm/llvm-project/pull/124838.diff

1 Files Affected:

(modified) llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp (+53-5)

diff --git a/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp b/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp
index 0f151c897d938e..0948452e8d19cf 100644
--- a/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp
+++ b/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp
@@ -175,6 +175,11 @@ bool VPlanVerifier::verifyEVLRecipe(const VPInstruction &EVL) const {
   });
 }
 
+/// Return true if \p R is a VPIRInstruction wrapping a phi.
+static bool isVPIRInstructionPhi(const VPRecipeBase &R) {
+  auto *VPIRI = dyn_cast<VPIRInstruction>(&R);
+  return VPIRI && isa<PHINode>(VPIRI->getInstruction());
+}
 bool VPlanVerifier::verifyVPBasicBlock(const VPBasicBlock *VPBB) {
   if (!verifyPhiRecipes(VPBB))
     return false;
@@ -207,14 +212,57 @@ bool VPlanVerifier::verifyVPBasicBlock(const VPBasicBlock *VPBB) {
 
       for (const VPUser *U : V->users()) {
         auto *UI = cast<VPRecipeBase>(U);
-        // TODO: check dominance of incoming values for phis properly.
-        if (!UI ||
-            isa<VPHeaderPHIRecipe, VPWidenPHIRecipe, VPPredInstPHIRecipe>(UI))
+        const VPBlockBase *UserVPBB = UI->getParent();
+
+        // Verify incoming values of VPIRInstructions wrapping phis. V most
+        // dominate the end of the incoming block. The operand index of the
+        // incoming value matches the predecessor block index of the
+        // corresponding incoming block.
+        if (isVPIRInstructionPhi(*UI)) {
+          for (const auto &[Idx, Op] : enumerate(UI->operands())) {
+            if (V != Op)
+              continue;
+            const VPBlockBase *Incoming = UserVPBB->getPredecessors()[Idx];
+            if (Incoming != VPBB && !VPDT.dominates(VPBB, Incoming)) {
+              errs() << "Use before def!\n";
+              return false;
+            }
+          }
           continue;
+        }
+        // Verify incoming value of various phi-like recipes.
+        if (isa<VPWidenPHIRecipe, VPHeaderPHIRecipe, VPPredInstPHIRecipe>(UI)) {
+          const VPBlockBase *Incoming = nullptr;
+          // Get the incoming block based on the number of predecessors.
+          if (UserVPBB->getNumPredecessors() == 0) {
+            assert((isa<VPWidenPHIRecipe>(UI) || isa<VPHeaderPHIRecipe>(UI)) &&
+                   "Unexpected recipe with 0 predecessors");
+            const VPRegionBlock *UserRegion = UserVPBB->getParent();
+            Incoming = V == UI->getOperand(0)
+                           ? UserRegion->getSinglePredecessor()
+                           : UserRegion->getExiting();
+          } else if (UserVPBB->getNumPredecessors() == 1) {
+            assert(isa<VPWidenPHIRecipe>(UI) &&
+                   "Unexpected recipe with 1 predecessors");
+            Incoming = UserVPBB->getSinglePredecessor();
+          } else {
+            assert(UserVPBB->getNumPredecessors() == 2 &&
+                   isa<VPPredInstPHIRecipe>(UI) &&
+                   "Unexpected recipe with 2 or more predecessors");
+            Incoming = UserVPBB->getPredecessors()[1];
+          }
+          if (auto *R = dyn_cast<VPRegionBlock>(Incoming))
+            Incoming = R->getExiting();
+          if (Incoming != VPBB && !VPDT.dominates(VPBB, Incoming)) {
+            errs() << "Use before def!\n";
+            return false;
+          }
+          continue;
+        }
 
         // If the user is in the same block, check it comes after R in the
         // block.
-        if (UI->getParent() == VPBB) {
+        if (UserVPBB == VPBB) {
           if (RecipeNumbering[UI] < RecipeNumbering[&R]) {
             errs() << "Use before def!\n";
             return false;
@@ -222,7 +270,7 @@ bool VPlanVerifier::verifyVPBasicBlock(const VPBasicBlock *VPBB) {
           continue;
         }
 
-        if (!VPDT.dominates(VPBB, UI->getParent())) {
+        if (!VPDT.dominates(VPBB, UserVPBB)) {
           errs() << "Use before def!\n";
           return false;
         }

llvmbot · 2025-01-28T21:11:01Z

@llvm/pr-subscribers-llvm-transforms

Author: Florian Hahn (fhahn)

Changes

Update the verifier to verify dominance for incoming values for phi-like recipes. The defining recipe must dominate the incoming block for the incoming value.

There are 4 different cases to consider when retrieving the incoming block:

VPIRInstructions wrapping phis: the incoming block from the blocks predecessors has the same index as the incoming value operand.
VPHeaderPhiRecipes, VPWidenPhi used in header: there's no predecessors; if the incoming value is the start value use the predecessor of the containing region, otherwise the exiting block of the region
1 predecessor: Must be a VPWidenPHI used as LCSSA phi; use the predecessor
2 predecessors: must be a VPPredInstPhiRecipe, use the second predecessor.

Full diff: https://github.com/llvm/llvm-project/pull/124838.diff

1 Files Affected:

(modified) llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp (+53-5)

diff --git a/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp b/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp
index 0f151c897d938e..0948452e8d19cf 100644
--- a/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp
+++ b/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp
@@ -175,6 +175,11 @@ bool VPlanVerifier::verifyEVLRecipe(const VPInstruction &EVL) const {
   });
 }
 
+/// Return true if \p R is a VPIRInstruction wrapping a phi.
+static bool isVPIRInstructionPhi(const VPRecipeBase &R) {
+  auto *VPIRI = dyn_cast<VPIRInstruction>(&R);
+  return VPIRI && isa<PHINode>(VPIRI->getInstruction());
+}
 bool VPlanVerifier::verifyVPBasicBlock(const VPBasicBlock *VPBB) {
   if (!verifyPhiRecipes(VPBB))
     return false;
@@ -207,14 +212,57 @@ bool VPlanVerifier::verifyVPBasicBlock(const VPBasicBlock *VPBB) {
 
       for (const VPUser *U : V->users()) {
         auto *UI = cast<VPRecipeBase>(U);
-        // TODO: check dominance of incoming values for phis properly.
-        if (!UI ||
-            isa<VPHeaderPHIRecipe, VPWidenPHIRecipe, VPPredInstPHIRecipe>(UI))
+        const VPBlockBase *UserVPBB = UI->getParent();
+
+        // Verify incoming values of VPIRInstructions wrapping phis. V most
+        // dominate the end of the incoming block. The operand index of the
+        // incoming value matches the predecessor block index of the
+        // corresponding incoming block.
+        if (isVPIRInstructionPhi(*UI)) {
+          for (const auto &[Idx, Op] : enumerate(UI->operands())) {
+            if (V != Op)
+              continue;
+            const VPBlockBase *Incoming = UserVPBB->getPredecessors()[Idx];
+            if (Incoming != VPBB && !VPDT.dominates(VPBB, Incoming)) {
+              errs() << "Use before def!\n";
+              return false;
+            }
+          }
           continue;
+        }
+        // Verify incoming value of various phi-like recipes.
+        if (isa<VPWidenPHIRecipe, VPHeaderPHIRecipe, VPPredInstPHIRecipe>(UI)) {
+          const VPBlockBase *Incoming = nullptr;
+          // Get the incoming block based on the number of predecessors.
+          if (UserVPBB->getNumPredecessors() == 0) {
+            assert((isa<VPWidenPHIRecipe>(UI) || isa<VPHeaderPHIRecipe>(UI)) &&
+                   "Unexpected recipe with 0 predecessors");
+            const VPRegionBlock *UserRegion = UserVPBB->getParent();
+            Incoming = V == UI->getOperand(0)
+                           ? UserRegion->getSinglePredecessor()
+                           : UserRegion->getExiting();
+          } else if (UserVPBB->getNumPredecessors() == 1) {
+            assert(isa<VPWidenPHIRecipe>(UI) &&
+                   "Unexpected recipe with 1 predecessors");
+            Incoming = UserVPBB->getSinglePredecessor();
+          } else {
+            assert(UserVPBB->getNumPredecessors() == 2 &&
+                   isa<VPPredInstPHIRecipe>(UI) &&
+                   "Unexpected recipe with 2 or more predecessors");
+            Incoming = UserVPBB->getPredecessors()[1];
+          }
+          if (auto *R = dyn_cast<VPRegionBlock>(Incoming))
+            Incoming = R->getExiting();
+          if (Incoming != VPBB && !VPDT.dominates(VPBB, Incoming)) {
+            errs() << "Use before def!\n";
+            return false;
+          }
+          continue;
+        }
 
         // If the user is in the same block, check it comes after R in the
         // block.
-        if (UI->getParent() == VPBB) {
+        if (UserVPBB == VPBB) {
           if (RecipeNumbering[UI] < RecipeNumbering[&R]) {
             errs() << "Use before def!\n";
             return false;
@@ -222,7 +270,7 @@ bool VPlanVerifier::verifyVPBasicBlock(const VPBasicBlock *VPBB) {
           continue;
         }
 
-        if (!VPDT.dominates(VPBB, UI->getParent())) {
+        if (!VPDT.dominates(VPBB, UserVPBB)) {
           errs() << "Use before def!\n";
           return false;
         }

david-arm

Thanks for this - looks sensible to me. I just had a couple of comments.

david-arm · 2025-01-29T09:02:01Z

+static bool isVPIRInstructionPhi(const VPRecipeBase &R) {
+  auto *VPIRI = dyn_cast<VPIRInstruction>(&R);
+  return VPIRI && isa<PHINode>(VPIRI->getInstruction());
+}


nit: Add new line after function?

Adde a newline, thanks

david-arm · 2025-01-29T09:30:48Z

+                   "Unexpected recipe with 2 or more predecessors");
+            Incoming = UserVPBB->getPredecessors()[1];
+          }
+          if (auto *R = dyn_cast<VPRegionBlock>(Incoming))


Just out of curiosity, what's the scenario where the incoming block for a VPWidenPHIRecipe, VPHeaderPHIRecipe or VPPredInstPHIRecipe recipe would be the region? Is it the recipes we create in the middle block? If so, could this check potentially fail with uncountable early exits, i.e. the incoming block is effectively the middle.split block? I assume it's fine, but just wondering if there are missing tests for all the scenarios.

The only case at the moment is in VPWidenPHIRecipes added in the VPlan-native path. I added an assert; it cannot happen in the inner-loop vectorizer path.

fhahn

ping :)

ayalz

Good to see this TODO being addressed, adding various comments.

ayalz · 2025-02-16T08:13:02Z

@@ -207,24 +213,69 @@ bool VPlanVerifier::verifyVPBasicBlock(const VPBasicBlock *VPBB) {

      for (const VPUser *U : V->users()) {
        auto *UI = cast<VPRecipeBase>(U);


unrelated nit:

Suggested change

auto *UI = cast<VPRecipeBase>(U);

auto *UR = cast<VPRecipeBase>(U);

Will fix independently.

ayalz · 2025-02-16T08:13:35Z

-             isa<PHINode>(cast<VPIRInstruction>(UI)->getInstruction())))
+        const VPBlockBase *UserVPBB = UI->getParent();
+
+        // Verify incoming values of VPIRInstructions wrapping phis. V most


Suggested change

// Verify incoming values of VPIRInstructions wrapping phis. V most

// Verify incoming values of VPIRInstructions wrapping phis. V must

fixed, thanks

ayalz · 2025-02-16T08:14:12Z

+
+        // Verify incoming values of VPIRInstructions wrapping phis. V most
+        // dominate the end of the incoming block. The operand index of the
+        // incoming value matches the predecessor block index of the


Suggested change

// incoming value matches the predecessor block index of the

// incoming value must match the predecessor block index of the

Done thanks!

ayalz · 2025-02-16T08:17:53Z

+        // incoming value matches the predecessor block index of the
+        // corresponding incoming block.
+        if (isVPIRInstructionPhi(*UI)) {
+          for (const auto &[Idx, Op] : enumerate(UI->operands())) {


Suggested change

for (const auto &[Idx, Op] : enumerate(UI->operands())) {

for (const auto &[Index, OpAtIndex] : enumerate(UI->operands())) {

ayalz · 2025-02-16T08:18:22Z

+          for (const auto &[Idx, Op] : enumerate(UI->operands())) {
+            if (V != Op)
+              continue;
+            const VPBlockBase *Incoming = UserVPBB->getPredecessors()[Idx];


Suggested change

const VPBlockBase *Incoming = UserVPBB->getPredecessors()[Idx];

const VPBlockBase *PredAtIndex = UserVPBB->getPredecessors()[Idx];

ayalz · 2025-02-16T15:25:53Z

+        if (isa<VPWidenPHIRecipe, VPHeaderPHIRecipe, VPPredInstPHIRecipe>(UI)) {
+          const VPBlockBase *Incoming = nullptr;
+          // Get the incoming block based on the number of predecessors.


nit: better switch over the types of recipes involved, asserting the number of predecessors, than vice-versa? Nearly every recipe seems to be doing its own thing anyhow.

Code has been replaced by type-switch and using incoming values/blocks iterator.

ayalz · 2025-02-16T15:29:44Z

+                   "Unexpected recipe with 2 or more predecessors");
+            Incoming = UserVPBB->getPredecessors()[1];
+          }
+          if (auto *R = dyn_cast<VPRegionBlock>(Incoming)) {


Suggested change

if (auto *R = dyn_cast<VPRegionBlock>(Incoming)) {

if (auto *IncomingRegion = dyn_cast<VPRegionBlock>(Incoming)) {

to avoid confusion with R which is also being used for the current Recipe.

Code is gone in latest version

ayalz · 2025-02-16T16:22:05Z

+                   "VPWidenPHIRecipe");
+            Incoming = R->getExiting();
+          }
+          if (Incoming != VPBB && !VPDT.dominates(VPBB, Incoming)) {


Same comment as above.

Code is gone in latest version

ayalz · 2025-02-16T16:26:32Z

+        // dominate the end of the incoming block. The operand index of the
+        // incoming value matches the predecessor block index of the
+        // corresponding incoming block.
+        if (isVPIRInstructionPhi(*UI)) {


Can the case of VPIRInstruction be handled along with all other phi recipes below?

There are cases where the block containing a VPIR Phi has multiple predecessors (some cases with early exits), for those we need the proper phi-handling

ayalz · 2025-02-16T16:27:27Z

+          continue;
+        }

        // If the user is in the same block, check it comes after R in the


Suggested change

// If the user is in the same block, check it comes after R in the

// If the user is in the same block, check that it comes after R in the

independent typo.

Yep can fix separately, thanks

Add a VPPhiAccessors class to provide interfaces to access incoming values and blocks, with corresponding iterators. The first user is VPWidenPhiRecipe, with the other phi-like recipes following soon. This will also be used to verify def-use chains where users are phi-like recipes, simplifying llvm#124838.

fhahn

I reworked the PR quite a bit and it is now building on a few additional patches:

Add interface to retrieve incoming blocks & values + iterators, usable for all phi-like recipes: #129387
Add VPIRPhi #129387

fhahn · 2025-02-24T22:33:04Z

+}
+
 bool VPlanVerifier::verifyVPBasicBlock(const VPBasicBlock *VPBB) {
  if (!verifyPhiRecipes(VPBB))


I am not sure how we could move the new code to verifyPhiRecipes, as here we verify def before use property looking at the uses of a defined VPValue and when looking at the uses we need to handle phi-like recipes.

fhahn · 2025-02-24T22:33:16Z


+/// Return true if \p R is a VPIRInstruction wrapping a phi.
+static bool isVPIRInstructionPhi(const VPRecipeBase &R) {
+  auto *VPIRI = dyn_cast<VPIRInstruction>(&R);


Will check separately, thanks!

fhahn · 2025-02-24T22:35:42Z

+}
+
 bool VPlanVerifier::verifyVPBasicBlock(const VPBasicBlock *VPBB) {
  if (!verifyPhiRecipes(VPBB))


It should be complete now, updated, thanks!

fhahn · 2025-02-24T22:36:09Z

@@ -207,24 +213,69 @@ bool VPlanVerifier::verifyVPBasicBlock(const VPBasicBlock *VPBB) {

      for (const VPUser *U : V->users()) {
        auto *UI = cast<VPRecipeBase>(U);


Will fix independently.

fhahn · 2025-02-24T22:36:25Z

-             isa<PHINode>(cast<VPIRInstruction>(UI)->getInstruction())))
+        const VPBlockBase *UserVPBB = UI->getParent();
+
+        // Verify incoming values of VPIRInstructions wrapping phis. V most


fixed, thanks

fhahn · 2025-02-24T22:36:40Z

+
+        // Verify incoming values of VPIRInstructions wrapping phis. V most
+        // dominate the end of the incoming block. The operand index of the
+        // incoming value matches the predecessor block index of the


Done thanks!

fhahn · 2025-02-24T22:39:30Z

+        // dominate the end of the incoming block. The operand index of the
+        // incoming value matches the predecessor block index of the
+        // corresponding incoming block.
+        if (isVPIRInstructionPhi(*UI)) {


There are cases where the block containing a VPIR Phi has multiple predecessors (some cases with early exits), for those we need the proper phi-handling

github-actions · 2025-03-01T16:16:59Z

✅ With the latest revision this PR passed the C/C++ code formatter.

Add a VPPhiAccessors class to provide interfaces to access incoming values and blocks, with corresponding iterators. The first user is VPWidenPhiRecipe, with the other phi-like recipes following soon. This will also be used to verify def-use chains where users are phi-like recipes, simplifying llvm#124838.

Similarly to VPInstructionWithType and VPIRPhi, add VPPhi as a subclass for VPInstruction. This allows implementing the VPPhiAccessors trait, making available helpers for generic printing of incoming values / blocks and accessors for incoming blocks and values. It will also allow properly verifying def-uses for values used by VPInstructions with PHI opcodes via llvm#124838.

…139151) Similarly to VPInstructionWithType and VPIRPhi, add VPPhi as a subclass for VPInstruction. This allows implementing the VPPhiAccessors trait, making available helpers for generic printing of incoming values / blocks and accessors for incoming blocks and values. It will also allow properly verifying def-uses for values used by VPInstructions with PHI opcodes via #124838. PR: #139151

…des.(NFC) (#139151) Similarly to VPInstructionWithType and VPIRPhi, add VPPhi as a subclass for VPInstruction. This allows implementing the VPPhiAccessors trait, making available helpers for generic printing of incoming values / blocks and accessors for incoming blocks and values. It will also allow properly verifying def-uses for values used by VPInstructions with PHI opcodes via llvm/llvm-project#124838. PR: llvm/llvm-project#139151

fhahn

Ping :)

Now that #138472 and #139151 landed, this should be ready for another look

david-arm · 2025-05-12T08:35:37Z


  /// Returns the number of incoming values, also number of incoming blocks.
-  unsigned getNumIncoming() const { return getAsRecipe()->getNumOperands(); }
+  /// Note that at the moment, VPWidenIntOrFpInductionRecipes only have a single


Looks like this still includes bits of #138472, which looks like it hasn't landed yet?

#138472 simply adds additional iterators, but that is optional and not needed for the verification patch itself; they both need handling for additional recipes in getNumIncoming though. Currently #138472 is more of a follow-up after this patch

ayalz · 2025-05-14T13:00:46Z

  /// Returns the number of incoming values, also number of incoming blocks.
-  unsigned getNumIncoming() const { return getAsRecipe()->getNumOperands(); }
+  /// Note that at the moment, VPWidenIntOrFpInductionRecipes only have a single
+  /// incoming value, its start value.


Better have VPWidenIntOrFpInductionRecipe override a virtual getNumIncoming()?

Done thanks

ayalz · 2025-05-14T13:28:26Z

+
+  static inline VPPhiAccessors *castFailed() { return nullptr; }
+
+  static inline VPPhiAccessors *doCastIfPossible(const VPRecipeBase *f) {


Where is doCastIfPossible used?

This is used by dyn_cast

ayalz · 2025-05-14T13:29:02Z

+
+  using Self = CastInfo<VPPhiAccessors, const VPRecipeBase *>;
+
+  using CastReturnType =


Where is CastReturnType used?

Unused in the latest version, removed, thanks!

ayalz · 2025-05-14T13:31:58Z

 };

+/// Casting from VPRecipeBase -> VPPhiAccessors is supported for all recipe
+/// types implementing VPPhiAccessors.


Is this scaffolding needed for dyn_cast<VPPhiAccessors>(RecipeBase*) to work, due to its multiple inheritance?

Yep as there's no link between RecipeBase and VPPhiAccessors. CastIsPossible is used for isa

ayalz · 2025-05-14T13:32:53Z

+/// Support casting from VPRecipeBase -> VPPhiAccessors, by down-casting to the
+/// recipe types implementing VPPhiAccessors.
+template <>
+struct CastInfo<VPPhiAccessors, const VPRecipeBase *>


Where is CastInfo used?

This is used by cast/dyn_cast to perform the actual cast.

ayalz · 2025-05-14T14:21:50Z

+            const VPBasicBlock *IncVPBB = Phi->getIncomingBlock(Idx);
+            if (IncVPV != V)
+              continue;
+            if (IncVPBB != VPBB && !VPDT.dominates(VPBB, IncVPBB)) {


dominates(VPBB, IncVPBB) returns true when VPBB == IncVPBB, so suffice to check if (!VPDT.dominates(VPBB, IncVPBB))? But is it ok to have VPBB == IncVPBB, given that U is a phi - only if V is a phi too and such dependences between two phi's of the same block are allowed in VPlan, where fixed order dependences are modelled with intervening splices - for VF>1?
In any case good to continue with early continue:

Suggested change

if (IncVPBB != VPBB && !VPDT.dominates(VPBB, IncVPBB)) {

if (VPDT.properlyDominates(VPBB, IncVPBB))

continue;

Updated to just dominates. We could have a loop with a single block, then the incoming value from the latch would be definined in the same block?

Ah, right; a value can be defined in the header and feed a header phi (of the same header block) even when the loop has additional blocks. Can check that in this case it's the 2nd incoming of the phi, i.e., across the backedge.

ayalz · 2025-05-14T14:28:11Z

+            VPValue *IncVPV = Phi->getIncomingValue(Idx);
+            const VPBasicBlock *IncVPBB = Phi->getIncomingBlock(Idx);
+            if (IncVPV != V)
+              continue;


Suggested change

VPValue *IncVPV = Phi->getIncomingValue(Idx);

const VPBasicBlock *IncVPBB = Phi->getIncomingBlock(Idx);

if (IncVPV != V)

continue;

VPValue *IncomingV = Phi->getIncomingValue(Idx);

if (IncomingV != V)

continue;

const VPBasicBlock *IncomingVPBB = Phi->getIncomingBlock(Idx);

Updated, thanks

ayalz · 2025-05-14T14:31:12Z

+/// types implementing VPPhiAccessors.
+template <> struct CastIsPossible<VPPhiAccessors, const VPRecipeBase *> {
+  static inline bool isPossible(const VPRecipeBase *f) {
+    return isa<VPIRPhi, VPHeaderPHIRecipe, VPWidenPHIRecipe, VPPhi>(f);


VPPredInstPHIRecipe might be another?

Yes, but I left it out for now because more work will be needed as there the operands also don't match the # of predecessors.

ayalz · 2025-05-14T14:32:22Z

+          }
+          continue;
+        }
+        if (isa<VPPredInstPHIRecipe>(UI))


Anything to check?

Yep, added a TODO for now, thanks

ayalz · 2025-05-14T14:32:46Z

+          continue;
+        }

        // If the user is in the same block, check it comes after R in the


independent typo.

ayalz

LGTM, thanks!

ayalz · 2025-05-14T22:51:09Z

 };

+/// Casting from VPRecipeBase -> VPPhiAccessors is supported for all recipe
+/// types implementing VPPhiAccessors.


Suggested change

/// types implementing VPPhiAccessors.

/// types implementing VPPhiAccessors. CastIsPossible is used by isa.

Adde a note, thanks!

ayalz · 2025-05-14T22:52:04Z

+/// Casting from VPRecipeBase -> VPPhiAccessors is supported for all recipe
+/// types implementing VPPhiAccessors.
+template <> struct CastIsPossible<VPPhiAccessors, const VPRecipeBase *> {
+  static inline bool isPossible(const VPRecipeBase *f) {


Suggested change

static inline bool isPossible(const VPRecipeBase *f) {

static inline bool isPossible(const VPRecipeBase *f) {

// TODO: include VPPredInstPHIRecipe too.

Added thanks

ayalz · 2025-05-14T22:53:09Z

+  }
+};
+/// Support casting from VPRecipeBase -> VPPhiAccessors, by down-casting to the
+/// recipe types implementing VPPhiAccessors.


Suggested change

/// recipe types implementing VPPhiAccessors.

/// recipe types implementing VPPhiAccessors. CastInfo is used by cast and dyn_cast.

Added thanks.

ayalz · 2025-05-14T22:54:02Z

+    }());
+  }
+
+  static inline VPPhiAccessors *doCastIfPossible(const VPRecipeBase *f) {


Suggested change

static inline VPPhiAccessors *doCastIfPossible(const VPRecipeBase *f) {

/// doCastIfPossible is used by dyn_cast.

static inline VPPhiAccessors *doCastIfPossible(const VPRecipeBase *f) {

added thanks

ayalz · 2025-05-14T22:58:12Z

+            if (IncVPV != V)
+              continue;
+            const VPBasicBlock *IncVPBB = Phi->getIncomingBlock(Idx);
+            if (!VPDT.dominates(VPBB, IncVPBB)) {


Another early-continue?

Suggested change

if (!VPDT.dominates(VPBB, IncVPBB)) {

if (VPDT.dominates(VPBB, IncVPBB))

continue;

updated thanks

ayalz · 2025-05-14T23:08:53Z

+            const VPBasicBlock *IncVPBB = Phi->getIncomingBlock(Idx);
+            if (IncVPV != V)
+              continue;
+            if (IncVPBB != VPBB && !VPDT.dominates(VPBB, IncVPBB)) {


Ah, right; a value can be defined in the header and feed a header phi (of the same header block) even when the loop has additional blocks. Can check that in this case it's the 2nd incoming of the phi, i.e., across the backedge.

ayalz · 2025-05-14T23:11:52Z

-             cast<VPInstruction>(UI)->getOpcode() == Instruction::PHI))
+        if (auto *Phi = dyn_cast<VPPhiAccessors>(UI)) {
+          for (unsigned Idx = 0; Idx != Phi->getNumIncoming(); ++Idx) {
+            VPValue *IncVPV = Phi->getIncomingValue(Idx);


"Inc" is ambiguous - e.g., also stands for "Increment". Hence suggested renaming to IncomingV and IncomingVPBB.

updated, thanks

llvm-ci · 2025-05-15T11:28:35Z

LLVM Buildbot has detected a new failure on builder llvm-clang-x86_64-win-fast running on as-builder-3 while building llvm at step 7 "test-build-unified-tree-check-llvm-unit".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/2/builds/24015

Here is the relevant piece of the build log for the reference

Step 7 (test-build-unified-tree-check-llvm-unit) failure: test (failure)
******************** TEST 'LLVM-Unit :: Transforms/Vectorize/./VectorizeTests.exe/46/51' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\build\unittests\Transforms\Vectorize\.\VectorizeTests.exe-LLVM-Unit-3468-46-51.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=51 GTEST_SHARD_INDEX=46 C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\build\unittests\Transforms\Vectorize\.\VectorizeTests.exe
--

Script:
--
C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\build\unittests\Transforms\Vectorize\.\VectorizeTests.exe --gtest_filter=VPVerifierTest.VPPhiIncomingValueDoesntDominateIncomingBlock
--
C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\llvm-project\llvm\unittests\Transforms\Vectorize\VPlanVerifierTest.cpp(178): error: Expected equality of these values:
  "Use before def!\n"
  ::testing::internal::GetCapturedStderr().c_str()
    Which is: "Incoming def at index 0 does not dominate incoming block!\n"


C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\llvm-project\llvm\unittests\Transforms\Vectorize\VPlanVerifierTest.cpp:178
Expected equality of these values:
  "Use before def!\n"
  ::testing::internal::GetCapturedStderr().c_str()
    Which is: "Incoming def at index 0 does not dominate incoming block!\n"



********************

llvm-ci · 2025-05-15T11:53:19Z

LLVM Buildbot has detected a new failure on builder sanitizer-aarch64-linux running on sanitizer-buildbot8 while building llvm at step 2 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/51/builds/16196

Here is the relevant piece of the build log for the reference

Step 2 (annotate) failure: 'python ../sanitizer_buildbot/sanitizers/zorg/buildbot/builders/sanitizers/buildbot_selector.py' (failure)
...
[182/186] Generating MSAN_INST_TEST_OBJECTS.msan_test.cpp.aarch64-with-call.o
[183/186] Generating Msan-aarch64-with-call-Test
[184/186] Generating MSAN_INST_TEST_OBJECTS.msan_test.cpp.aarch64.o
[185/186] Generating Msan-aarch64-Test
[185/186] Running compiler_rt regression tests
llvm-lit: /home/b/sanitizer-aarch64-linux/build/llvm-project/llvm/utils/lit/lit/discovery.py:276: warning: input '/home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/interception/Unit' contained no tests
llvm-lit: /home/b/sanitizer-aarch64-linux/build/llvm-project/llvm/utils/lit/lit/discovery.py:276: warning: input '/home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/sanitizer_common/Unit' contained no tests
llvm-lit: /home/b/sanitizer-aarch64-linux/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 5915 tests, 72 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
FAIL: libFuzzer-aarch64-static-libcxx-Linux :: reduce_inputs.test (5833 of 5915)
******************** TEST 'libFuzzer-aarch64-static-libcxx-Linux :: reduce_inputs.test' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
rm -rf /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C # RUN: at line 3
+ rm -rf /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C
mkdir -p /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C # RUN: at line 4
+ mkdir -p /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C
/home/b/sanitizer-aarch64-linux/build/build_default/./bin/clang    -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta   --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/lib/fuzzer  -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta  /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/ShrinkControlFlowSimpleTest.cpp -o /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest # RUN: at line 5
+ /home/b/sanitizer-aarch64-linux/build/build_default/./bin/clang -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/lib/fuzzer -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/ShrinkControlFlowSimpleTest.cpp -o /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest
/home/b/sanitizer-aarch64-linux/build/build_default/./bin/clang    -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta   --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/lib/fuzzer  -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta  /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/ShrinkControlFlowTest.cpp -o /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowTest # RUN: at line 6
+ /home/b/sanitizer-aarch64-linux/build/build_default/./bin/clang -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/lib/fuzzer -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/ShrinkControlFlowTest.cpp -o /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowTest
/home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest  -exit_on_item=0eb8e4ed029b774d80f2b66408203801cb982a60   -runs=1000000 /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C 2>&1 | FileCheck /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test # RUN: at line 7
+ /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest -exit_on_item=0eb8e4ed029b774d80f2b66408203801cb982a60 -runs=1000000 /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C
+ FileCheck /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test
/home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest -runs=0 /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C 2>&1 | FileCheck /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test --check-prefix=COUNT # RUN: at line 11
+ FileCheck /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test --check-prefix=COUNT
+ /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest -runs=0 /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C
/home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test:12:8: error: COUNT: expected string not found in input
COUNT: seed corpus: files: 4
       ^
<stdin>:1:1: note: scanning from here
INFO: Running with entropic power schedule (0xFF, 100).
^
<stdin>:7:7: note: possible intended match here
INFO: seed corpus: files: 3 min: 2b max: 3b total: 7b rss: 32Mb
      ^

Input file: <stdin>
Check file: /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            1: INFO: Running with entropic power schedule (0xFF, 100). 
check:12'0     X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
Step 9 (test compiler-rt symbolizer) failure: test compiler-rt symbolizer (failure)
...
[182/186] Generating MSAN_INST_TEST_OBJECTS.msan_test.cpp.aarch64-with-call.o
[183/186] Generating Msan-aarch64-with-call-Test
[184/186] Generating MSAN_INST_TEST_OBJECTS.msan_test.cpp.aarch64.o
[185/186] Generating Msan-aarch64-Test
[185/186] Running compiler_rt regression tests
llvm-lit: /home/b/sanitizer-aarch64-linux/build/llvm-project/llvm/utils/lit/lit/discovery.py:276: warning: input '/home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/interception/Unit' contained no tests
llvm-lit: /home/b/sanitizer-aarch64-linux/build/llvm-project/llvm/utils/lit/lit/discovery.py:276: warning: input '/home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/sanitizer_common/Unit' contained no tests
llvm-lit: /home/b/sanitizer-aarch64-linux/build/llvm-project/llvm/utils/lit/lit/main.py:72: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 5915 tests, 72 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
FAIL: libFuzzer-aarch64-static-libcxx-Linux :: reduce_inputs.test (5833 of 5915)
******************** TEST 'libFuzzer-aarch64-static-libcxx-Linux :: reduce_inputs.test' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
rm -rf /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C # RUN: at line 3
+ rm -rf /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C
mkdir -p /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C # RUN: at line 4
+ mkdir -p /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C
/home/b/sanitizer-aarch64-linux/build/build_default/./bin/clang    -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta   --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/lib/fuzzer  -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta  /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/ShrinkControlFlowSimpleTest.cpp -o /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest # RUN: at line 5
+ /home/b/sanitizer-aarch64-linux/build/build_default/./bin/clang -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/lib/fuzzer -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/ShrinkControlFlowSimpleTest.cpp -o /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest
/home/b/sanitizer-aarch64-linux/build/build_default/./bin/clang    -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta   --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/lib/fuzzer  -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta  /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/ShrinkControlFlowTest.cpp -o /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowTest # RUN: at line 6
+ /home/b/sanitizer-aarch64-linux/build/build_default/./bin/clang -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/lib/fuzzer -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/ShrinkControlFlowTest.cpp -o /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowTest
/home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest  -exit_on_item=0eb8e4ed029b774d80f2b66408203801cb982a60   -runs=1000000 /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C 2>&1 | FileCheck /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test # RUN: at line 7
+ /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest -exit_on_item=0eb8e4ed029b774d80f2b66408203801cb982a60 -runs=1000000 /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C
+ FileCheck /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test
/home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest -runs=0 /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C 2>&1 | FileCheck /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test --check-prefix=COUNT # RUN: at line 11
+ FileCheck /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test --check-prefix=COUNT
+ /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp-ShrinkControlFlowSimpleTest -runs=0 /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/fuzzer/AARCH64StaticLibcxxLinuxConfig/Output/reduce_inputs.test.tmp/C
/home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test:12:8: error: COUNT: expected string not found in input
COUNT: seed corpus: files: 4
       ^
<stdin>:1:1: note: scanning from here
INFO: Running with entropic power schedule (0xFF, 100).
^
<stdin>:7:7: note: possible intended match here
INFO: seed corpus: files: 3 min: 2b max: 3b total: 7b rss: 32Mb
      ^

Input file: <stdin>
Check file: /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/test/fuzzer/reduce_inputs.test

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            1: INFO: Running with entropic power schedule (0xFF, 100). 
check:12'0     X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found

vvereschaka · 2025-05-17T01:10:03Z

@fhahn ,

these changes cause a crash for the following tests on the expensive check builders such as llvm-clang-x86_64-expensive-checks-ubuntu:

first-order-recurrence.ll
pointer_iv.ll
pr48340.ll

more details here https://lab.llvm.org/buildbot/#/builders/187/builds/5956

/home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/build/bin/opt -passes=loop-vectorize --force-vector-width=4 --force-vector-interleave=0 -S -o - < /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/test/Transforms/LoopVectorize/X86/pr48340.ll | /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/build/bin/FileCheck /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/test/Transforms/LoopVectorize/X86/pr48340.ll # RUN: at line 2
+ /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/build/bin/opt -passes=loop-vectorize --force-vector-width=4 --force-vector-interleave=0 -S -o -
+ /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/build/bin/FileCheck /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/test/Transforms/LoopVectorize/X86/pr48340.ll
opt: /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/VPlan.cpp:787: const llvm::VPBasicBlock* llvm::VPBasicBlock::getCFGPredecessor(unsigned int) const: Assertion `Idx < 2 && Region->getNumPredecessors() == 1 && "loop region has a single predecessor (preheader), its entry block " "has 2 incoming blocks"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/build/bin/opt -passes=loop-vectorize --force-vector-width=4 --force-vector-interleave=0 -S -o -
1.	Running pass "function(loop-vectorize<no-interleave-forced-only;no-vectorize-forced-only;>)" on module "<stdin>"
2.	Running pass "loop-vectorize<no-interleave-forced-only;no-vectorize-forced-only;>" on function "foo"
 #0 0x00005581969b7064 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Support/Unix/Signals.inc:804:22
 #1 0x00005581969b74f7 PrintStackTraceSignalHandler(void*) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Support/Unix/Signals.inc:888:1
 #2 0x00005581969b48b3 llvm::sys::RunSignalHandlers() /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Support/Signals.cpp:105:20
 #3 0x00005581969b68d3 SignalHandler(int, siginfo_t*, void*) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Support/Unix/Signals.inc:418:13
 #4 0x00007fc006abf520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #5 0x00007fc006b139fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
 #6 0x00007fc006abf476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
 #7 0x00007fc006aa57f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
 #8 0x00007fc006aa571b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
 #9 0x00007fc006ab6e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#10 0x0000558193c88f1b llvm::VPBasicBlock::getCFGPredecessor(unsigned int) const /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/VPlan.cpp:793:21
#11 0x00005581939f1a4c llvm::VPPhiAccessors::getIncomingBlock(unsigned int) const /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/VPlan.h:3487:1
#12 0x0000558193d3a979 (anonymous namespace)::VPlanVerifier::verifyVPBasicBlock(llvm::VPBasicBlock const*) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp:228:69
#13 0x0000558193d3b32c (anonymous namespace)::VPlanVerifier::verifyBlock(llvm::VPBlockBase const*) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp:362:16
#14 0x0000558193d3b452 (anonymous namespace)::VPlanVerifier::verifyBlocksInRegion(llvm::VPRegionBlock const*) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp:373:9
#15 0x0000558193d3b5cf (anonymous namespace)::VPlanVerifier::verifyRegion(llvm::VPRegionBlock const*) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp:393:37
#16 0x0000558193d3b670 (anonymous namespace)::VPlanVerifier::verifyRegionRec(llvm::VPRegionBlock const*) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp:398:31
#17 0x0000558193d3b7e2 (anonymous namespace)::VPlanVerifier::verify(llvm::VPlan const&) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp:412:7
#18 0x0000558193d3baf2 llvm::verifyVPlanIsValid(llvm::VPlan const&) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/VPlanVerifier.cpp:461:25
#19 0x0000558193a0ae3d void llvm::VPlanTransforms::runPass<unsigned int, llvm::LLVMContext&>(void (*)(llvm::VPlan&, unsigned int, llvm::LLVMContext&), llvm::VPlan&, std::remove_reference<unsigned int>::type&, std::remove_reference<llvm::LLVMContext&>::type&) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/VPlanTransforms.h:54:3
#20 0x00005581939c5c1f llvm::LoopVectorizationPlanner::executePlan(llvm::ElementCount, unsigned int, llvm::VPlan&, llvm::InnerLoopVectorizer&, llvm::DominatorTree*, bool) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7796:27
#21 0x00005581939d7f2c llvm::LoopVectorizePass::processLoop(llvm::Loop*) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:10980:24
#22 0x00005581939d859a llvm::LoopVectorizePass::runImpl(llvm::Function&) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:11059:27
#23 0x00005581939d88e7 llvm::LoopVectorizePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:11096:39
#24 0x0000558192f7e657 llvm::detail::PassModel<llvm::Function, llvm::LoopVectorizePass, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:92:3
#25 0x00005581966d27ad llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:85:18
#26 0x0000558190a78fab llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:92:3
#27 0x00005581966d1682 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/lib/IR/PassManager.cpp:129:23
#28 0x0000558190a78d25 llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:92:3
#29 0x00005581966d23d9 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/include/llvm/IR/PassManagerImpl.h:85:18
#30 0x00005581901732f9 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::PassPlugin>, llvm::ArrayRef<std::function<void (llvm::PassBuilder&)>>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/tools/opt/NewPMDriver.cpp:557:10
#31 0x00005581901437eb optMain /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/tools/opt/optdriver.cpp:729:27
#32 0x0000558190141001 main /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/tools/opt/opt.cpp:25:64
#33 0x00007fc006aa6d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#34 0x00007fc006aa6e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#35 0x0000558190140ee5 _start (/home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/build/bin/opt+0xfdeee5)
FileCheck error: '<stdin>' is empty.

would you fix the problem as soon as it possible or revert these changes

fhahn · 2025-05-17T09:44:21Z

@vvereschaka should be back to green after b3e7e4b

fhahn requested review from alexey-bataev, aniragil, ayalz and david-arm January 28, 2025 21:10

llvmbot added vectorizers llvm:transforms labels Jan 28, 2025

fhahn mentioned this pull request Jan 28, 2025

[LoopVectorize] Enable vectorisation of early exit loops with live-outs #120567

Merged

david-arm reviewed Jan 29, 2025

View reviewed changes

fhahn force-pushed the vplan-verify-def-use-phi branch from 29aa9b0 to 695ef3c Compare January 29, 2025 20:47

fhahn force-pushed the vplan-verify-def-use-phi branch from 695ef3c to 129e8ad Compare February 15, 2025 21:16

fhahn commented Feb 15, 2025

View reviewed changes

ayalz reviewed Feb 16, 2025

View reviewed changes

fhahn mentioned this pull request Mar 1, 2025

[VPlan] Add VPPhiAccessors to provide interface for phi recipes (NFC) #129388

Merged

fhahn force-pushed the vplan-verify-def-use-phi branch from 129e8ad to bbd3712 Compare March 1, 2025 16:13

fhahn commented Mar 1, 2025

View reviewed changes

fhahn added 9 commits March 13, 2025 15:07

Merge remote-tracking branch 'origin/main' into vplan-phi-accessors

9113022

!fixup address latest comments, thanks

c61233f

Merge remote-tracking branch 'origin/main' into vplan-phi-accessors

a73a137

Merge remote-tracking branch 'origin/main' into vplan-phi-accessors

90b2d4d

!fixup address latest comments, thanks

f768b97

Merge remote-tracking branch 'origin/main' into vplan-phi-accessors

d6d6bb5

Merge remote-tracking branch 'origin/main' into vplan-phi-accessors

8dfd569

!fixup address latest comments, thanks

595b057

Merge remote-tracking branch 'origin/main' into vplan-phi-accessors

a2b4ebb

fhahn added 4 commits May 11, 2025 15:47

Merge remote-tracking branch 'origin/main' into vplan-verify-def-use-phi

31eec38

!fixup update after merging f2e62cf.

60d5ec9

Merge remote-tracking branch 'origin/main' into vplan-verify-def-use-phi

5554c6d

!fixup fix formatting

ba48230

fhahn commented May 11, 2025

View reviewed changes

david-arm reviewed May 12, 2025

View reviewed changes

fhahn added 3 commits May 13, 2025 08:46

Merge remote-tracking branch 'origin/main' into vplan-verify-def-use-phi

8e60892

Merge remote-tracking branch 'origin/main' into vplan-verify-def-use-phi

370eaf1

!fxup improve verifier message, add verification test.

56d4784

ayalz reviewed May 14, 2025

View reviewed changes

fhahn added 2 commits May 14, 2025 19:20

Merge remote-tracking branch 'origin/main' into vplan-verify-def-use-phi

d4317a8

!fixup address latest comments, thanks!

d371f10

ayalz approved these changes May 14, 2025

View reviewed changes

fhahn added 2 commits May 15, 2025 10:59

Merge remote-tracking branch 'origin/main' into vplan-verify-def-use-phi

e5cf64d

!fixup address latest comments, thanks!

5fa41af

fhahn merged commit 8bbe0d0 into llvm:main May 15, 2025

fhahn deleted the vplan-verify-def-use-phi branch May 15, 2025 11:20

		@@ -207,24 +213,69 @@ bool VPlanVerifier::verifyVPBasicBlock(const VPBasicBlock *VPBB) {

		for (const VPUser *U : V->users()) {
		auto *UI = cast<VPRecipeBase>(U);

	auto *UI = cast<VPRecipeBase>(U);
	auto *UR = cast<VPRecipeBase>(U);

	// Verify incoming values of VPIRInstructions wrapping phis. V most
	// Verify incoming values of VPIRInstructions wrapping phis. V must

	// incoming value matches the predecessor block index of the
	// incoming value must match the predecessor block index of the

	for (const auto &[Idx, Op] : enumerate(UI->operands())) {
	for (const auto &[Index, OpAtIndex] : enumerate(UI->operands())) {

	const VPBlockBase *Incoming = UserVPBB->getPredecessors()[Idx];
	const VPBlockBase *PredAtIndex = UserVPBB->getPredecessors()[Idx];

	if (auto *R = dyn_cast<VPRegionBlock>(Incoming)) {
	if (auto *IncomingRegion = dyn_cast<VPRegionBlock>(Incoming)) {

	// If the user is in the same block, check it comes after R in the
	// If the user is in the same block, check that it comes after R in the


		static inline VPPhiAccessors *castFailed() { return nullptr; }

		static inline VPPhiAccessors doCastIfPossible(const VPRecipeBase f) {


		using Self = CastInfo<VPPhiAccessors, const VPRecipeBase *>;

		using CastReturnType =

	if (IncVPBB != VPBB && !VPDT.dominates(VPBB, IncVPBB)) {
	if (VPDT.properlyDominates(VPBB, IncVPBB))
	continue;

	/// types implementing VPPhiAccessors.
	/// types implementing VPPhiAccessors. CastIsPossible is used by isa.

	static inline bool isPossible(const VPRecipeBase *f) {
	static inline bool isPossible(const VPRecipeBase *f) {
	// TODO: include VPPredInstPHIRecipe too.

	/// recipe types implementing VPPhiAccessors.
	/// recipe types implementing VPPhiAccessors. CastInfo is used by cast and dyn_cast.

	static inline VPPhiAccessors doCastIfPossible(const VPRecipeBase f) {
	/// doCastIfPossible is used by dyn_cast.
	static inline VPPhiAccessors doCastIfPossible(const VPRecipeBase f) {

	if (!VPDT.dominates(VPBB, IncVPBB)) {
	if (VPDT.dominates(VPBB, IncVPBB))
	continue;

Conversation

fhahn commented Jan 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

llvmbot commented Jan 28, 2025

Uh oh!

llvmbot commented Jan 28, 2025

Uh oh!

david-arm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fhahn left a comment

Choose a reason for hiding this comment

Uh oh!

ayalz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fhahn left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fhahn commented Jan 28, 2025 •

edited

Loading

github-actions Bot commented Mar 1, 2025 •

edited

Loading