This is an archive of the discontinued LLVM Phabricator instance.

[VPlan] Update VPValue::getDef to return VPRecipeBase* (NFC).
ClosedPublic

Authored by fhahn on Oct 17 2022, 4:20 AM.

Details

Summary

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.

Diff Detail

Event Timeline

fhahn created this revision.Oct 17 2022, 4:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 17 2022, 4:20 AM
fhahn requested review of this revision.Oct 17 2022, 4:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 17 2022, 4:20 AM
Ayal added a comment.Oct 23 2022, 11:08 AM

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

Documentation?

112

Empty line separator?

1111

Append the newly created recipe directly instead of upcasting it to VPValue and back?

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

Rephrase comment and/or return a reference?

fhahn updated this revision to Diff 473655.Nov 7 2022, 7:05 AM
fhahn marked 3 inline comments as done.

A more accurate name for getDef() may then be getDefiningRecipe(), as in MLIR's Value::getDefiningOp().

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!

fhahn added inline comments.Nov 7 2022, 1:17 PM
llvm/lib/Transforms/Vectorize/VPlan.cpp
111

added in the header, thanks

112

done, thanks!

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

updated to return a reference

Ayal accepted this revision.Nov 15 2022, 7:14 AM

This looks good to me, thanks. Adding various nits, mostly irrespective of this patch.

A more accurate name for getDef() may then be getDefiningRecipe(), as in MLIR's Value::getDefiningOp().

Updated, thanks!

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.

8489

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).

9900–9901

nit: comment deserves updating? (irrespective of this patch)

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

Append the newly created recipe directly instead of upcasting it to VPValue and back?

i.e.,

VPExpandSCEVRecipe *StepR = new VPExpandSCEVRecipe(Expr, SE);
Preheader->appendRecipe(StepR);
return StepR;

?
(somewhat irrespective of this patch)

llvm/lib/Transforms/Vectorize/VPlanValue.h
205

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 ↗(On Diff #473655)

nit: check instead that it's not null? (irrespective of this patch)

817 ↗(On Diff #473655)

nit: dyn_cast is redundant.

845 ↗(On Diff #473655)

ditto x 2, here and below

This revision is now accepted and ready to land.Nov 15 2022, 7:14 AM
This revision was landed with ongoing or failed builds.Nov 16 2022, 2:12 PM
This revision was automatically updated to reflect the committed changes.
fhahn marked 9 inline comments as done.Nov 16 2022, 3:14 PM

Thanks for taking a look! The independent suggestions should have been addressed separately.

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
8489

Thanks, should be fixed with bcc9c5d959b9.

9900–9901

Done in 239b52d4b6f6, thanks!

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

Oh right, this was independent of the patch! Updated in aa16689f82a0, thanks!

llvm/lib/Transforms/Vectorize/VPlanValue.h
205

Done in 55f56cdc3329, thanks!

llvm/unittests/Transforms/Vectorize/VPlanTest.cpp
816 ↗(On Diff #473655)

Thanks, should all be addressed in b52d328ee8aa.