[VPlan] Remove VPPredInstPHIRecipe::useScalars#143798
Conversation
It uses the vector value of its operand if possible. Use the default definition in VPUser, which is false since onlyFirstLaneUsed is false. From the discussion at llvm#142594 (comment)
|
@llvm/pr-subscribers-vectorizers @llvm/pr-subscribers-llvm-transforms Author: Luke Lau (lukel97) ChangesIt uses the vector value of its operand if possible. Use the default definition in VPUser, which is false since onlyFirstLaneUsed is false. From the discussion at #142594 (comment) Full diff: https://github.com/llvm/llvm-project/pull/143798.diff 1 Files Affected:
diff --git a/llvm/lib/Transforms/Vectorize/VPlan.h b/llvm/lib/Transforms/Vectorize/VPlan.h
index bbcbfee4e471b..5b8a80d5bbd21 100644
--- a/llvm/lib/Transforms/Vectorize/VPlan.h
+++ b/llvm/lib/Transforms/Vectorize/VPlan.h
@@ -2951,13 +2951,6 @@ class VPPredInstPHIRecipe : public VPSingleDefRecipe {
void print(raw_ostream &O, const Twine &Indent,
VPSlotTracker &SlotTracker) const override;
#endif
-
- /// Returns true if the recipe uses scalars of operand \p Op.
- bool usesScalars(const VPValue *Op) const override {
- assert(is_contained(operands(), Op) &&
- "Op must be an operand of the recipe");
- return true;
- }
};
/// A common base class for widening memory operations. An optional mask can be
|
fhahn
left a comment
There was a problem hiding this comment.
oh so this doesn't handle the case from #142594 (comment)?
No it doesn't cause that broadcast to be hoisted, the scalar VP operand is already outside of the loop body. That case in #142594 I guess just shows how the broadcast itself can be hoisted. But I don't think it's important if LICM is going to do it afterwards anyway |
It uses the vector value of its operand if possible. Use the default definition in VPUser, which is false since onlyFirstLaneUsed is false.
From the discussion at #142594 (comment)
I don't think this is strictly NFC but I couldn't really think of a way to come up for a test case for it