This patch makes VPRecipeBase a direct subclass of VPDef, moving the
SubclassID to VPDef.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
---|---|---|
113 | IIUC this is still necessary since VPInstruction doesn't register itself as a VPValue in its VPDef (ownership issue?). Does this mean that using the VPDef::defined_values() API won't work when VPInstructions are involved? |
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
---|---|---|
113 |
Using VPDef for VPInstruction required a bit of extra churn in the original version of the patches. That is why the patch turning VPInstruction into a VPDef is a bit out-of-order. D90565 turns VPInstruction into a VPDef and allows us to get rid of toVPValue. I just updated the patch to do so. With that patch, definedValues should work as expected for all recipes. |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
---|---|---|
622 | yes I added one. For now, it just returns true, as all VPDefs are also VPRecipeBases at the moment. If they diverge, we need to check the IDs. | |
693 | I also updated the other classof calls which were using VPDef *V. | |
710 | I added a comment to VPRecipeBase. Otherwise we would have to add the same comment to all subclasses of VPRecipeBase. Do you think that is sufficient or should I add the comment to the subclasses? |
Great thanks! This depends on a set of patches turning individual recipes into VPDefs. They should be linked correctly in Phabricator now.
Should there be a VPRecipeBase::classof(VPDef *) to support dyn_cast from VPDef to VPRecipeBase?