a SmallPtrSet. Currently, there is no need for stable iteration in this
dimension, and I now thing there won't need to be going forward.
If this is ever re-introduced in any form, it needs to not be
a SetVector based solution because removal cannot be linear. There will
be many SCCs with large numbers of parents. When encountering these, the
incremental SCC update for intra-SCC edge removal was quadratic due to
linear removal (kind of).
I'm really hoping we can avoid having an ordering property here at all
though...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207091
91177308-0d34-0410-b5e6-
96231b3b80d8
friend class LazyCallGraph;
friend class LazyCallGraph::Node;
- SmallSetVector<SCC *, 1> ParentSCCs;
+ SmallPtrSet<SCC *, 1> ParentSCCs;
SmallVector<Node *, 1> Nodes;
SCC() {}
public:
typedef SmallVectorImpl<Node *>::const_iterator iterator;
- typedef pointee_iterator<SmallSetVector<SCC *, 1>::const_iterator> parent_iterator;
+ typedef pointee_iterator<SmallPtrSet<SCC *, 1>::const_iterator> parent_iterator;
iterator begin() const { return Nodes.begin(); }
iterator end() const { return Nodes.end(); }
// the caller no longer a parent of the callee. Walk the other call edges
// in the caller to tell.
if (!HasOtherCallToCalleeC) {
- bool Removed = CalleeC.ParentSCCs.remove(this);
+ bool Removed = CalleeC.ParentSCCs.erase(this);
(void)Removed;
assert(Removed &&
"Did not find the caller SCC in the callee SCC's parent list!");
// However, we do need to remove this SCC from its SCC's parent set.
SCC &ChildSCC = *G.SCCMap.lookup(&ChildN);
if (&ChildSCC != this) {
- ChildSCC.ParentSCCs.remove(this);
+ ChildSCC.ParentSCCs.erase(this);
continue;
}