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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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.
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. |
nit: I'd add something like "Function is templated to support both const and non-const blocks" for clarity.