The return value of getDef is guaranteed to be a VPRecipeBase and all
users can also accept a VPRecipeBase *. Most users actually case to
VPRecipeBase or a specific recipe before using it, so this change
removes a number of redundant casts.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
A more accurate name for getDef() may then be getDefiningRecipe(), as in MLIR's Value::getDefiningOp().
Using cast_or_null() effectively implies that VPDef is a pure base-class having VPRecipeBase as its sole direct subclass. If this is (and will continue to be) the case, should VPDef's constructor be non-public, and VPDef be an internal subclass of VPRecipeBase rather than a base-class thereof? The original intention was for VPDef to be analogous to VPUser, but live-in's are represented with VPValue's having no VPDef whereas live-out's are represented with the VPLiveOut subclass of VPUser - sibling of VPRecipeBase.
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
---|---|---|
111–119 | Documentation? | |
112 | Empty line separator? | |
1114 | Append the newly created recipe directly instead of upcasting it to VPValue and back? | |
llvm/lib/Transforms/Vectorize/VPlan.h | ||
1177–1179 | Rephrase comment and/or return a reference? |
Updated, thanks!
Using cast_or_null() effectively implies that VPDef is a pure base-class having VPRecipeBase as its sole direct subclass. If this is (and will continue to be) the case, should VPDef's constructor be non-public, and VPDef be an internal subclass of VPRecipeBase rather than a base-class thereof? The original intention was for VPDef to be analogous to VPUser, but live-in's are represented with VPValue's having no VPDef whereas live-out's are represented with the VPLiveOut subclass of VPUser - sibling of VPRecipeBase.
Sounds good as a separate refactoring!
This looks good to me, thanks. Adding various nits, mostly irrespective of this patch.
Very good, thanks!
Using cast_or_null() effectively implies that VPDef is a pure base-class having VPRecipeBase as its sole direct subclass. If this is (and will continue to be) the case, should VPDef's constructor be non-public, and VPDef be an internal subclass of VPRecipeBase rather than a base-class thereof? The original intention was for VPDef to be analogous to VPUser, but live-in's are represented with VPValue's having no VPDef whereas live-out's are represented with the VPLiveOut subclass of VPUser - sibling of VPRecipeBase.
Sounds good as a separate refactoring!
Sure, a todo can be left behind.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
1053–1054 | Comment: it's fine to retain the Def suffix of variable names even though they are no longer VPDef but are now VPRecipeBase, because they represent a Defining recipe. | |
8486–8487 | nit: the return of cast_or_null may be null, but code below dereferences RepR expecting it to be non-null (irrespective of this patch). | |
9876–9877 | nit: comment deserves updating? (irrespective of this patch) | |
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
1114 |
i.e., VPExpandSCEVRecipe *StepR = new VPExpandSCEVRecipe(Expr, SE); Preheader->appendRecipe(StepR); return StepR; ? | |
llvm/lib/Transforms/Vectorize/VPlanValue.h | ||
207 | nit: should we introduce a hasDefiningRecipe() returning a boolean to better support cases that currently check if (VPV->getDefiningRecipe())? | |
llvm/unittests/Transforms/Vectorize/VPlanTest.cpp | ||
816–817 | nit: check instead that it's not null? (irrespective of this patch) | |
817 | nit: dyn_cast is redundant. | |
845 | ditto x 2, here and below |
Thanks for taking a look! The independent suggestions should have been addressed separately.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
8486–8487 | Thanks, should be fixed with bcc9c5d959b9. | |
9876–9877 | Done in 239b52d4b6f6, thanks! | |
llvm/lib/Transforms/Vectorize/VPlan.cpp | ||
1114 | Oh right, this was independent of the patch! Updated in aa16689f82a0, thanks! | |
llvm/lib/Transforms/Vectorize/VPlanValue.h | ||
207 | Done in 55f56cdc3329, thanks! | |
llvm/unittests/Transforms/Vectorize/VPlanTest.cpp | ||
816–817 | Thanks, should all be addressed in b52d328ee8aa. |
Comment: it's fine to retain the Def suffix of variable names even though they are no longer VPDef but are now VPRecipeBase, because they represent a Defining recipe.