This is an archive of the discontinued LLVM Phabricator instance.

[VPlan] Remove duplicated VPValue IDs (NFCI).
ClosedPublic

Authored by fhahn on Jan 2 2023, 10:09 AM.

Details

Summary

At the moment, both VPValue and VPDef have an ID used when casting via
classof. This duplication is cumbersome, because it requires adding IDs
for new recipes twice and also requires setting them twice. In a few
cases, there's only a VPDef ID and no VPValue ID, which can cause same
confusion.

To simplify things, remove the VPValue IDs for different recipes.
Instead, only retain the generic VPValue ID (= used VPValues without a
corresponding defining recipe) and VPVRecipe for VPValues that are
defined by recipes that inherit from VPValue.

Diff Detail

Event Timeline

fhahn created this revision.Jan 2 2023, 10:09 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 2 2023, 10:09 AM
fhahn requested review of this revision.Jan 2 2023, 10:09 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 2 2023, 10:09 AM
Ayal added a comment.Jan 15 2023, 3:57 PM

Nice cleanup!

llvm/lib/Transforms/Vectorize/VPlan.h
757–758

nit: unrelated to this patch, but wonder if the above can be improved.

917

nit: is VPRecipeBase:: needed here but unneeded in the constructor above? Worth being consistent throughout, and hopefully cleanup more.

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

Is this enumeration really needed? Is a VPValueSC always a live-in, i.e., a VPValue w/o a defining recipe?
From the summary: "... only retain the generic VPValue ID (= used VPValues without a
corresponding defining recipe) ..."

nit: "A VPValue sub-class that is a VPRecipeBase and also inherits from VPValue" - Any VPValue sub-class surely also inherits from VPValue... (Worth /// if needed?)

95–100

Should the "VPValueSC" constructor of VPValue above accept only a Value* as a single optional operand,
and the "VPVRecipeSC" constructor below be called whenever a (non-null) VPDef* is provided?
Deserves a comment.
Also worth indicating in the commit message that the operands are swapped to facilitate an optional underlying value.

fhahn updated this revision to Diff 489475.Jan 16 2023, 2:39 AM
fhahn marked 2 inline comments as done.

Address comments, thanks!

fhahn marked 2 inline comments as done.Jan 16 2023, 2:43 AM
fhahn added inline comments.
llvm/lib/Transforms/Vectorize/VPlan.h
757–758

I think it is not needed any longer now that getDefinigRecipe returns VPRecipeBase which already is a direct subclass of VPUser. I will remove it separately.

917

Consistently update all uses I could find to use VPDef:: which is the place where the VPDef IDs are actually defined: 56ffd39c3da89dc94ed7d7122fe5765e09429289

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

Is this enumeration really needed? Is a VPValueSC always a live-in, i.e., a VPValue w/o a defining recipe?

VPValueSC is also used for VPValues defined by recipes that define multiple results. Those do not inherit from VPValue. I updated the comment to make it clearer.

nit: "A VPValue sub-class that is a VPRecipeBase and also inherits from VPValue" - Any VPValue sub-class surely also inherits from VPValue... (Worth /// if needed?)

Remove the and also... bit and added ///.

95–100

I split up the constructors into separate ones for the 3 cases:

  1. live in
  2. def has multiple defined values
  3. def is VPValue subclass

and added comments.

Ayal accepted this revision.Jan 16 2023, 11:09 AM

OK, thanks for clarifying.
It's somewhat confusing to have the order of parameters dictate which VPValue is being constructed, but the alternative of having each subclass provide its VPDefID seems less appealing.
Perhaps once a common base class is introduced to take care of all recipes that also inherit from VPValue it could pass VPVRecipeSC explicitly when constructing VPValue, rather than relying on this order.

This revision is now accepted and ready to land.Jan 16 2023, 11:09 AM
fhahn updated this revision to Diff 489812.Jan 17 2023, 7:07 AM
fhahn marked 2 inline comments as done.

Rebase before landing.

OK, thanks for clarifying.
It's somewhat confusing to have the order of parameters dictate which VPValue is being constructed, but the alternative of having each subclass provide its VPDefID seems less appealing.
Perhaps once a common base class is introduced to take care of all recipes that also inherit from VPValue it could pass VPVRecipeSC explicitly when constructing VPValue, rather than relying on this order.

A common base class for recipes inheriting from VPValue may be a good way forward. I'll look into this as follow-up!

This revision was landed with ongoing or failed builds.Jan 17 2023, 7:12 AM
This revision was automatically updated to reflect the committed changes.
fhahn added inline comments.Jan 17 2023, 7:19 AM
llvm/lib/Transforms/Vectorize/VPlan.h
757–758