[llvm] [VPlan] Move tail folding out of VPlanPredicator. NFC (PR #176143)

Luke Lau via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 21 20:29:27 PST 2026


lukel97 wrote:

> Isn't it what predicator sees for the original control flow from VPlan construction (modulo "vector mask" -> "varying i1 condition" renaming, which are essentially the same anyway)?

Yes but the vector mask condition is the problem since VPInstruction::BranchOnCond isn't designed as a masking construct but for regular control flow, i.e. see VPInstruction::usesFirstLaneOnly where it states the condition operand is scalar. In retrospect I think it was more a coincidence that VPPredicator happened to work with it because it was automatically broadcasting scalars when predicating.

> VPlan is in consistent (and potentially verifiable) state

Even if we do add PHIs in the latch to keep SSA, the BranchOnCond instructions will be invalid so it will fail the VPlanVerifier anyway. FWIW I'm not strongly opinionated on either approach

> Do you know if the verifier would have caught that?

Yes it checks for domination, but at this stage during VPlan construction it doesn't pass anyway because e.g. unhandled VPInstruction opcodes that aren't yet widened to VPWidenRecipe.

> I think https://github.com/llvm/llvm-project/pull/172454 would be a good candidate for using the masked VPInsruction capabilities from https://github.com/llvm/llvm-project/pull/142285; for early exits, we can mask the relevant VPInstructions early.

I didn't notice that PR before, I think we could use it for both this PR and #172454. But we would need to teach VPlanPredicator to logically-and masks with each VPInstructions' existing mask. I'm not sure if we would then need to keep around a cache or something so that we don't end up with a logical-and for each VPInstruction.



https://github.com/llvm/llvm-project/pull/176143


More information about the llvm-commits mailing list