Previously if the inliner split an SCC such that an empty one remained, the MLInlineAdvisor could potentially lose track of the EdgeCount if a subsequent CGSCC pass modified the calls of a function that was initially in the SCC pre-split. Saving the seen nodes in onPassEntry resolves this.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
lg, some nits
llvm/lib/Analysis/MLInlineAdvisor.cpp | ||
---|---|---|
182 | point out we're reusing NodesInLastSCC for that, so it's clear that this is the intent: 1) drain it (lines 160-180), 2) remember. I'd even add an assert(NodesInLastSCC.empty()) right above the for loop - same reason, clarifies the design intent Finally: I think you can do NodesInLastSCC.insert(LastSCC.begin(), LastSCC.end()) or smth like that (skipping the for) | |
211 | nit: you can do this: auto I = NodesInLastSCC.insert(&N) if (I.second) EdgedOfLastSeenNodes +=... this way the lookup is done once |
llvm/lib/Analysis/MLInlineAdvisor.cpp | ||
---|---|---|
182 | got it! but using SCC iterators won't work since we're inserting node pointers here, while the iterators would return nodes |
llvm/lib/Analysis/MLInlineAdvisor.cpp | ||
---|---|---|
182 | ah, ok |
This comment was removed by Northbadge.
point out we're reusing NodesInLastSCC for that, so it's clear that this is the intent: 1) drain it (lines 160-180), 2) remember.
I'd even add an assert(NodesInLastSCC.empty()) right above the for loop - same reason, clarifies the design intent
Finally: I think you can do NodesInLastSCC.insert(LastSCC.begin(), LastSCC.end()) or smth like that (skipping the for)