This is an archive of the discontinued LLVM Phabricator instance.

[VPlan] Track current vector loop in VPTransformState (NFC).
ClosedPublic

Authored by fhahn on Mar 14 2022, 10:17 AM.

Details

Summary

Instead of looking up the vector loop using the header, keep track of
the current vector loop in VPTransformState. This removes the
requirement for the vector header block being part of the loop up front.

A follow-up patch will move the code to generate the Loop object for the
vector loop to VPRegionBlock.

Depends on D121619.

Diff Detail

Event Timeline

fhahn created this revision.Mar 14 2022, 10:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 14 2022, 10:17 AM
fhahn requested review of this revision.Mar 14 2022, 10:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 14 2022, 10:17 AM
Herald added a subscriber: vkmr. · View Herald Transcript
Ayal added inline comments.Mar 27 2022, 8:13 AM
llvm/lib/Transforms/Vectorize/VPlan.cpp
912

Is CFG.LastBB now redundant, retrievable from CurrentVectorLoop->getExitBlock()?
(Or could CurrentVectorLoop be retrieved from LastBB'd predecessor, if unique.)

llvm/lib/Transforms/Vectorize/VPlan.h
355

Worth documenting?

Ayal added inline comments.Mar 27 2022, 9:16 AM
llvm/lib/Transforms/Vectorize/VPlan.cpp
912

(State->CurrentVectorLoop itself is also caching of State->LI->getLoopFor(State->CFG.VectorHeaderBB))

fhahn updated this revision to Diff 418605.Mar 28 2022, 8:52 AM
fhahn marked 3 inline comments as done.

Address latest comments.

llvm/lib/Transforms/Vectorize/VPlan.cpp
912

Is CFG.LastBB now redundant, retrievable from CurrentVectorLoop->getExitBlock()?

Unfortunately this only works if we maintain a correct branch to the exit block throughout VPlan execution. But we change the header branch to unreachable, so the won't work I think.

(Or could CurrentVectorLoop be retrieved from LastBB'd predecessor, if unique.)
(State->CurrentVectorLoop itself is also caching of State->LI->getLoopFor(State->CFG.VectorHeaderBB))

The main motivation for this change is to be able to create new loop objects for each non-replicator region during VPRegionBlock::execute. At that point, no basic blocks for the loop exist and when creating the first block in the loop (in VPBasicBlock::execute), there's no previous block we could use to get the loop object. We could change VPRegionBlock::execute to create a dummy block on entry, but keeping track of the loop object explicitly seems cleaner to me.

llvm/lib/Transforms/Vectorize/VPlan.h
355

Thanks, I added a comment!

Ayal accepted this revision.Mar 29 2022, 12:02 PM

This is fine; adding a clarifying comment.

llvm/lib/Transforms/Vectorize/VPlan.cpp
912

(This now relates to CFG.ExitBB instead of CFG.LastBB)

Ok, right; disconnecting the branch from VectorHeaderBB to middleBlock below will invalidate L->getExitBlock(), so ExitBB needs to be recorded above.

The current skeleton still creates VectorPreHeaderBB, VectorHeaderBB, and ExitBB/middleBlock, right? That's how L is retrieved above; the comment only clarifies that CurrentVectorLoop currently caches this retrieval (which should still be valid via the cumbersome
State->LI->getLoopFor(State->CFG.VectorPreHeader->getSingleSuccessor()))).
When that changes, and VectorHeaderBB is created during VPlan::execute() etc., the "Assumes a single LoopVectorBody basic-block was created" comment above should also be updated.

(In any case, no dummy blocks intended)

This revision is now accepted and ready to land.Mar 29 2022, 12:02 PM
This revision was landed with ongoing or failed builds.Mar 30 2022, 2:17 PM
This revision was automatically updated to reflect the committed changes.