[all-commits] [llvm/llvm-project] d9cbce: [CGSCC][Inliner] Handle new non-trivial edges in u...

[aeubanks via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: d9cbceb041fda981e5bb14f4cbea712302fc9cdb
      https://github.com/llvm/llvm-project/commit/d9cbceb041fda981e5bb14f4cbea712302fc9cdb
  Author: Arthur Eubanks <aeubanks at google.com>
  Date:   2020-11-11 (Wed, 11 Nov 2020)

  Changed paths:
    M llvm/lib/Analysis/CGSCCPassManager.cpp
    M llvm/lib/Transforms/IPO/Inliner.cpp
    M llvm/unittests/Analysis/CGSCCPassManagerTest.cpp

  Log Message:
  -----------
  [CGSCC][Inliner] Handle new non-trivial edges in updateCGAndAnalysisManagerForPass

Previously the inliner did a bit of a hack by adding ref edges for all
new edges introduced by performing an inline before calling
updateCGAndAnalysisManagerForPass(). This was because
updateCGAndAnalysisManagerForPass() didn't handle new non-trivial call
edges.

This adds handling of non-trivial call edges to
updateCGAndAnalysisManagerForPass().  The inliner called
updateCGAndAnalysisManagerForFunctionPass() since it was handling adding
newly introduced edges (so updateCGAndAnalysisManagerForPass() would
only have to handle promotion), but now it needs to call
updateCGAndAnalysisManagerForCGSCCPass() since
updateCGAndAnalysisManagerForPass() is now handling the new call edges
and function passes cannot add new edges.

We follow the previous path of adding trivial ref edges then letting promotion
handle changing the ref edges to call edges and the CGSCC updates. So
this still does not allow adding call edges that result in an addition
of a non-trivial ref edge.

This is in preparation for better detecting devirtualization. Previously
since the inliner itself would add ref edges,
updateCGAndAnalysisManagerForPass() would think that promotion and thus
devirtualization had happened after any sort of inlining.

Reviewed By: asbirlea

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