This is an archive of the discontinued LLVM Phabricator instance.

[VPlan] Add ParentPlan pointer to VPBlockBase.
ClosedPublic

Authored by fhahn on Feb 11 2020, 2:26 PM.

Details

Summary

This is mostly to help the VPSlotTracker in D73078. I would slightly prefer the ParentPlan to be a reference. I think that would be fine for all current uses, except that the tests in VPlanTest.cpp need updating . They are the only place that instantiates VPBasicBlocks without a VPlan.

Diff Detail

Event Timeline

fhahn created this revision.Feb 11 2020, 2:26 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 11 2020, 2:26 PM
gilr added a comment.Mar 1 2020, 7:01 AM

An alternative to adding a VPlan* to every VP block might be to reuse their existing Parent property by having (only) the topmost block's parent point to VPlan, similar to the IR hierarchy where ancestors are reached indirectly through transitivity. This would require VPlan to inherit from VPRegion, which may deserve further discussion.
For now let's go ahead with the suggested VPlan pointer in VPBlockBase, but better just call it get/Plan instead of get/ParentPlan, saving parenthood's existing semantics.
Since the only current use case for this is debugging, we can simplify the patch and maintain a future trivial switch to the above by setting only the entry block's VPlan e.g. at VPlan::setEntry() and have getPlan() traverse upwards until reaching a topmost block and backwards until reaching the entry. This also better supports potential moving blocks in and out of VPlans.
Makes sense?

fhahn updated this revision to Diff 247520.Mar 1 2020, 2:15 PM

An alternative to adding a VPlan* to every VP block might be to reuse their existing Parent property by having (only) the topmost block's parent point to VPlan, similar to the IR hierarchy where ancestors are reached indirectly through transitivity. This would require VPlan to inherit from VPRegion, which may deserve further discussion.
For now let's go ahead with the suggested VPlan pointer in VPBlockBase, but better just call it get/Plan instead of get/ParentPlan, saving parenthood's existing semantics.
Since the only current use case for this is debugging, we can simplify the patch and maintain a future trivial switch to the above by setting only the entry block's VPlan e.g. at VPlan::setEntry() and have getPlan() traverse upwards until reaching a topmost block and backwards until reaching the entry. This also better supports potential moving blocks in and out of VPlans.
Makes sense?

Sounds good to me. Updated the patch accordingly. I've used getParent() in order to find the top-most entry block.

gilr accepted this revision.Mar 3 2020, 2:12 AM

LGTM, with minor fix.

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

nit: I'd add something like "Function is templated to support both const and non-const blocks" for clarity.

68

This would wrongfully return nullptr for multiple predecessors. Better use *getPredecessors().begin() after checking that there are any.

This revision is now accepted and ready to land.Mar 3 2020, 2:12 AM
fhahn marked 2 inline comments as done.Mar 3 2020, 2:42 AM
fhahn added inline comments.
llvm/lib/Transforms/Vectorize/VPlan.cpp
60

Will do before committing.

68

Agreed! I think currently we do not really generate such CFGs on the top-level, due to the nesting with region blocks, but I'll generalize it to explore all predecessors until we reach one without any predecessors.

This revision was automatically updated to reflect the committed changes.