[all-commits] [llvm/llvm-project] 7fea56: [CGSCC][Coroutine][NewPM] Properly support functio...

[aeubanks via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 7fea561eb1ce0a339f3c47f6d89d2e9fa8706ab0
      https://github.com/llvm/llvm-project/commit/7fea561eb1ce0a339f3c47f6d89d2e9fa8706ab0
  Author: Arthur Eubanks <aeubanks at google.com>
  Date:   2021-01-06 (Wed, 06 Jan 2021)

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

  Log Message:
  -----------
  [CGSCC][Coroutine][NewPM] Properly support function splitting/outlining

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.

Reviewed By: rnk

Differential Revision: https://reviews.llvm.org/D93828