-
Notifications
You must be signed in to change notification settings - Fork 15.2k
[VPlan] Sink retrieving legacy costs to more specific computeCost impls. #109708
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 3 commits
8117ba1
f409232
0bf2760
9f12dab
16ca2ca
f632630
c75d678
d32eb48
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -275,20 +275,15 @@ void VPRecipeBase::moveBefore(VPBasicBlock &BB, | |||||||||
| } | ||||||||||
|
|
||||||||||
| /// Return the underlying instruction to be used for computing \p R's cost via | ||||||||||
| /// the legacy cost model. Return nullptr if there's no suitable instruction. | ||||||||||
| /// the legacy cost model. Return nullptr if there's no suitable instruction or | ||||||||||
| /// computeCost is already implemented for the recipe and there is no need for | ||||||||||
| /// the underlying instruction, i.e. it does not need to be skipped for cost | ||||||||||
| /// computations. | ||||||||||
|
||||||||||
| static Instruction *getInstructionForCost(const VPRecipeBase *R) { | ||||||||||
| if (auto *S = dyn_cast<VPSingleDefRecipe>(R)) | ||||||||||
| return dyn_cast_or_null<Instruction>(S->getUnderlyingValue()); | ||||||||||
|
||||||||||
| if (auto *IG = dyn_cast<VPInterleaveRecipe>(R)) | ||||||||||
| return IG->getInsertPos(); | ||||||||||
| // Currently the legacy cost model only calculates the instruction cost with | ||||||||||
| // underlying instruction. Removing the WidenMem here will prevent | ||||||||||
| // force-target-instruction-cost overwriting the cost of recipe with | ||||||||||
| // underlying instruction which is inconsistent with the legacy model. | ||||||||||
| // TODO: Remove WidenMem from this function when we don't need to compare to | ||||||||||
| // the legacy model. | ||||||||||
| if (auto *WidenMem = dyn_cast<VPWidenMemoryRecipe>(R)) | ||||||||||
| return &WidenMem->getIngredient(); | ||||||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Worth leaving a note, that even though widen loads and stores have an underlying instruction ("ingredient"), null is returned - in order to match legacy cost model behavior with force-target-instruction-cost? The instruction a recipe provides for cost affects both
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Clarified the the comment about the return value for the function. Nullptr is returned if either the recipe doesn't have an underlying instruction or computeCost is implemented and there is no need for the underlying instruction (i.e. it should not be needed to be skipped)
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Regarding the "else" part of this "or" - not needing UI because recipe is not to be skipped is fine (if it's absence from SkipCostComputation it won't be skipped), but would UI still be needed in order to apply ForceTargetInstructionCost?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This has been reworked in the latest version. The function is gone and inline to |
||||||||||
| return nullptr; | ||||||||||
| } | ||||||||||
|
|
||||||||||
|
|
@@ -298,9 +293,13 @@ InstructionCost VPRecipeBase::cost(ElementCount VF, VPCostContext &Ctx) { | |||||||||
| return 0; | ||||||||||
|
||||||||||
|
|
||||||||||
| InstructionCost RecipeCost = computeCost(VF, Ctx); | ||||||||||
| if (UI && ForceTargetInstructionCost.getNumOccurrences() > 0 && | ||||||||||
| RecipeCost.isValid()) | ||||||||||
| if (ForceTargetInstructionCost.getNumOccurrences() > 0 && | ||||||||||
| (RecipeCost.isValid() && RecipeCost != InstructionCost::getMax())) | ||||||||||
| RecipeCost = InstructionCost(ForceTargetInstructionCost); | ||||||||||
| // Max cost is used as a sentinel value to detect recipes without underlying | ||||||||||
| // instructions for which no forced target instruction cost should be applied. | ||||||||||
|
||||||||||
| else if (RecipeCost == InstructionCost::getMax()) | ||||||||||
|
||||||||||
| RecipeCost = 0; | ||||||||||
|
|
||||||||||
| LLVM_DEBUG({ | ||||||||||
| dbgs() << "Cost of " << RecipeCost << " for VF " << VF << ": "; | ||||||||||
|
|
@@ -312,15 +311,19 @@ InstructionCost VPRecipeBase::cost(ElementCount VF, VPCostContext &Ctx) { | |||||||||
| InstructionCost VPRecipeBase::computeCost(ElementCount VF, | ||||||||||
| VPCostContext &Ctx) const { | ||||||||||
| // Compute the cost for the recipe falling back to the legacy cost model using | ||||||||||
| // the underlying instruction. If there is no underlying instruction, returns | ||||||||||
| // 0. | ||||||||||
| // the underlying instruction. If there is no underlying instruction or the | ||||||||||
| // cost is computed by the recipe's computeCost, returns | ||||||||||
|
||||||||||
| // InstructionCost::getMax. It is used as a sentinel value to detect recipes | ||||||||||
|
||||||||||
| // InstructionCost::getMax. It is used as a sentinel value to detect recipes | |
| // InstructionCost::getMax. It is used as a sentinel value to detect recipes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment gone in the latest version.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // without underlying instructions for which no forced target instruction cost | |
| // should be applied. | |
| // without underlying instructions for which forced target instruction cost | |
| // should not be applied. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment gone in the latest version.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(independent) Have VPReplicateRecipe::computeCost() take care of inserting UI into SkipCostComputation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no such implementation yet, but can be added soon! Now moved slightly closer to VPSingleDefRecipe::computeCost.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that replicate recipes by definition must have a UI, so the latter can be asserted instead of checked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, thanks!
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment above about returning zero when no underlying instruction is there, should be updated.
Under ForceTargetInstructionCost, all UI's with valid costs are assigned ForceTargetInstructionCost cost. Therefore, under ForceTargetInstructionCost, all recipes w/ UI's and valid costs should also be assigned this cost, and all recipes w/o UI's should be assigned zero cost?
Need to distinguish between (zero, but could be any other valid) cost of a recipe that has no underlying, which should be ignored by ForceTargetInstructionCost because legacy only addresses UI's, and recipes w/ underlying (whose legacy cost is returned, can be zero or any other valid cost) which are subject to ForceTargetInstructionCost.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<Move the comment above to update the existing comment, thanks!
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps the default base-class implementation of VPRecipeBase::computeCost() should return null, delegating the fallback use of Ctx.getLegacyCost(UI, VF) to its caller VPRecipeBase::cost(), as outlined above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adjusted to use getLegacyCost in a few relevant sub-classes (VPSingleDefRecipe/VPInterleaveRecipe). Should hopefully be clearer and simpler now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The underlying instruction can be passed as argument, except that this base implementation should be a default for all derived VPlan-based computations, where the latter should be independent on UI, if possible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, also there are some computeCost implementation for recipes with underlying instruction, for which the default should not trigger. In particular, all recipes which currently have computeCost implemented in subclasses should be included with force-target-instruction-cost.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps better to return no cost at all, as in optional, when cost should be ignored, rather than a max sentinel. The latter requires additional attention to remain unmodified, preventing (mistaken) updates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change is not needed in latest version.