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

Arthur Eubanks via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Dec 26 13:48:00 PST 2020


aeubanks created this revision.
Herald added subscribers: lxfind, hiraditya.
aeubanks requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Previously when trying to support CoroSplit's function splitting, we
added in a hack that simply added the new function's node into the
original function's SCC (https://reviews.llvm.org/D87798). This is
incorrect since it might be in its own SCC.

Now, more similar to the previous design, we have callers explicitly
notify the LazyCallGraph that a function has been split out from another
one.

In order to properly support CoroSplit, there are two ways functions can
be split out.

One is the normal expected "outlining" of one function into a new one.
The new function may only contain references to other functions that the
original did. The original function must reference the new function. The
new function may reference the original function, which can result in
the new function being in the same SCC as the original function. The
weird case is when the original function indirectly references the new
function, but the new function directly calls the original function,
resulting in the new SCC being a parent of the original function's SCC.
This form of function splitting works with CoroSplit's Switch ABI.

The second way of splitting is more specific to CoroSplit. CoroSplit's
Retcon and Async ABIs split the original function into multiple
functions that all reference each other and are referenced by the
original function. In order to keep the LazyCallGraph in a valid state,
all new functions must be processed together, else some nodes won't be
populated. To keep things simple, this only supports the case where all
new edges are ref edges, and every new function references every other
new function. There can be a reference back from any new function to the
original function, putting all functions in the same RefSCC.

This also adds asserts that all nodes in a (Ref)SCC can reach all other
nodes to prevent future incorrect hacks.

The original hacks in https://reviews.llvm.org/D87798 are no longer
necessary since all new functions should have been registered before
calling updateCGAndAnalysisManagerForPass.

This fixes all coroutine tests when opt's -enable-new-pm is true by
default. This also fixes PR48190, which was likely due to the previous
hack breaking SCC invariants.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93828

Files:
  llvm/include/llvm/Analysis/LazyCallGraph.h
  llvm/include/llvm/Transforms/Utils/CallGraphUpdater.h
  llvm/lib/Analysis/CGSCCPassManager.cpp
  llvm/lib/Analysis/LazyCallGraph.cpp
  llvm/lib/Transforms/Coroutines/CoroSplit.cpp
  llvm/lib/Transforms/IPO/OpenMPOpt.cpp
  llvm/lib/Transforms/Utils/CallGraphUpdater.cpp
  llvm/test/Transforms/Coroutines/coro-async.ll
  llvm/test/Transforms/Coroutines/coro-retcon-resume-values2.ll
  llvm/test/Transforms/Coroutines/coro-split-recursive.ll
  llvm/unittests/Analysis/CGSCCPassManagerTest.cpp
  llvm/unittests/Analysis/LazyCallGraphTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D93828.313763.patch
Type: text/x-patch
Size: 43437 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201226/c0a276a4/attachment.bin>


More information about the llvm-commits mailing list