[PATCH] D24226: [PM] Provide an initial, minimal port of the inliner to the new pass manager.

[Chandler Carruth via llvm-commits]

chandlerc created this revision.
chandlerc added a reviewer: sanjoy.
chandlerc added a subscriber: llvm-commits.
chandlerc added a dependency: D24225: [LCG] Add the necessary functionality to the LazyCallGraph to support inlining..
Herald added subscribers: eraman, mcrosier, mehdi_amini.

This doesn't implement *every* feature of the existing inliner, but
tries to implement the most important ones for building a functional
optimization pipeline and beginning to sort out bugs, regressions, and
other problems.

Notable, but intentional omissions:
- No alloca merging support. Why? Because it isn't clear we want to do
  this at all. Active discussion and investigation is going on to remove
  it, so for simplicity I omitted it.
- No support for trying to iterate on "internally" devirtualized calls.
  Why? Because it adds what I suspect is inappropriate coupling for
  little or no benefit. We will have an outer iteration system that
  tracks devirtualization including that from function passes and
  iterates already. We should improve that rather than approximate it
  here.
- Optimization remarks. Why? Purely to make the patch smaller, no other
  reason at all.

Note that of these, the last two are the ones I expect to need to
implement eventually. The last one I'll probably do almost immediately.
But I wanted to skip it in the initial patch to try to focus the change
as much as possible as there is already a lot of code moving around and
both of these *could* be skipped without really disrupting the core
logic.

A summary of the different things happening here:

1) Adding the usual new PM class and rigging.

2) Fixing minor underlying assumptions in the inline cost analysis or
   inline logic that don't generally hold in the new PM world.

3) Adding the core pass logic which is in essence a loop over the calls
   in the nodes in the call graph. This is a bit duplicated from the old
   inliner, but only a handful of lines could realistically be shared.
   (I tried at first, and it really didn't help anything.) All told,
   this is only about 100 lines of code, and most of that is the
   mechanics of wiring up analyses from the new PM world.

4) Updating the LazyCallGraph (in the new PM) based on the *newly
   inlined* calls and references. This is very minimal because we cannot
   form cycles.

5) When inlining removes the last use of a function, eagerly updating
   the call graph and deleting the function so that any "one use
   remaining" inline cost heuristics are immediately refined. This is
   pretty minor in the inliner at 15 or so lines.

6) After all the inlining for a particular function, updating the
   LazyCallGraph and the CGSCC pass manager to reflect the removed call
   edges and function references. Both of these can happen just be
   removing the call instruction that is inlined, but I've implemented
   this as a generalized "DCE" update because we run InstSimplify as we
   process inlined instructions and I don't want to constrain how far we
   constant fold. Ultimately, it adds no real complexity to handle the
   full "DCE" cases. The logic here is similar but not precisely the
   same as the fully general function-pass update. The reason for the
   difference is for efficiency. We can build the necessary sets
   up-front and early exit in the cases where all called functions or
   referenced functions are accounted for. All told this is just over
   100 lines. I'd still like to find a way to simplify this, as it feels
   like more code than should be necessary but I've not found anything
   that is really an improvement. (Mostly found things that make it
   shorter but harder to read and understand.)

7) Refactoring the existing CGSCC update logic to share as much code as
   possible when implementing #6.

While the patch delta is somewhat large, much of this is moving code out
to helper functions. I can separate these into NFC refactoring patches
that I land ahead of time but it didn't make sense as I would have no
way to explain the *particular* refactoring without adding the second
caller to that API here.

The really substantial delta is 100 lines of inliner and under 300 lines
of CGSCC update, which seems fairly reasonable for the core of all this
madness. =] The rest are comments, APIs in headers, and boiler plate fro
the new pass.

Depends on D24225

https://reviews.llvm.org/D24226

Files:
  include/llvm/Analysis/CGSCCPassManager.h
  include/llvm/Analysis/LazyCallGraph.h
  include/llvm/Transforms/IPO/Inliner.h
  include/llvm/Transforms/IPO/InlinerPass.h
  lib/Analysis/CGSCCPassManager.cpp
  lib/Analysis/InlineCost.cpp
  lib/Analysis/LazyCallGraph.cpp
  lib/Passes/PassBuilder.cpp
  lib/Passes/PassRegistry.def
  lib/Transforms/IPO/AlwaysInliner.cpp
  lib/Transforms/IPO/InlineSimple.cpp
  lib/Transforms/IPO/Inliner.cpp
  test/Transforms/Inline/basictest.ll
  test/Transforms/Inline/nested-inline.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D24226.70307.patch
Type: text/x-patch
Size: 39590 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160905/db3a3bc6/attachment.bin>