[llvm] [GVN] Look through select/phi when determining underlying object (PR #99509)
Nikita Popov via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 18 09:13:07 PDT 2024
================
@@ -6609,6 +6609,48 @@ void llvm::getUnderlyingObjects(const Value *V,
} while (!Worklist.empty());
}
+const Value *
+llvm::getUnderlyingObjectThroughPhisAndSelects(const Value *V,
+ unsigned MaxLookup) {
+ const unsigned MaxVisited = 8;
+
+ SmallPtrSet<const Value *, 8> Visited;
+ SmallVector<const Value *, 8> Worklist;
+ Worklist.push_back(V);
+ const Value *Object = nullptr, *FirstObject = nullptr;
+ do {
+ const Value *P = Worklist.pop_back_val();
+ P = getUnderlyingObject(P, MaxLookup);
+
+ if (!FirstObject)
+ FirstObject = P;
+
+ if (!Visited.insert(P).second)
+ continue;
+
+ if (Visited.size() == MaxVisited)
+ return FirstObject;
+
+ if (auto *SI = dyn_cast<SelectInst>(P)) {
+ Worklist.push_back(SI->getTrueValue());
+ Worklist.push_back(SI->getFalseValue());
+ continue;
+ }
+
+ if (auto *PN = dyn_cast<PHINode>(P)) {
----------------
nikic wrote:
I believe that we don't need that isSameUnderlyingObjectInLoop() logic as long as we're reducing down to a single underlying object. What this handles is the case where you have underlying objects from different loop iterations that have the same SSA value -- this is the same basic issue as "value equal in potential cycles" in BasicAA.
However, if we're reducing to a single object, then this can't happen, because we have both a contribution from the pre-header and the loop. The loop contribution has to reduce back to the loop phi to end up with a single object. If it reduces to a loop variant value, then we'd have at least two underlying objects.
https://github.com/llvm/llvm-project/pull/99509
More information about the llvm-commits
mailing list