[PATCH] D93828: [CGSCC][Coroutine][NewPM] Properly support function splitting/outlining

Arthur Eubanks via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 30 12:06:10 PST 2020


aeubanks added inline comments.


================
Comment at: llvm/lib/Analysis/LazyCallGraph.cpp:1625
+
+  for (Instruction &I : instructions(OriginalFunction)) {
+    if (auto *CB = dyn_cast<CallBase>(&I)) {
----------------
lxfind wrote:
> aeubanks wrote:
> > lxfind wrote:
> > > Would it be better to implement getEdgeKind() by iterating through the list of edges from the Node that corresponds to OriginalFunction? (that way you can also assert on the Ref Edge in release mode without extra overhead)
> > This is used in cases where we don't have the edges populated yet. For example, the original function's node hasn't been updated to add the new edge when the split function is called. It's also useful for making sure that edges actually correspond to the instructions.
> > Added a comment.
> > 
> > I initially wanted the user of addSplitFunction() to specify the edge kind so we wouldn't have to calculate it here, but found that it was very easy to choose the wrong edge kind, and it's harder to use for little benefit.
> From what I see, this seems a common pattern in code:
>   LazyCallGraph::Edge &E : N.populate() {...}
`N.populate()` will only look through the function once to populate the edges once. If the edges have already been populated, it won't look through the function body again.
For example, `updateCGAndAnalysisManagerForPass()` has to look through the function body itself in order to find new/removed edges for an existing node.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93828/new/

https://reviews.llvm.org/D93828



More information about the llvm-commits mailing list