Home

[PM] Add a new "lazy" call graph analysis pass for the new pass manager.

Press ? to show keyboard shortcuts.
Committed
chandlercFeb 5 2014, 8:37 PM
Parents
rL200902: [PM] Back out one hunk of the patch in r200901 that was *supposed* to go
Branches
Unknown
Tags
Unknown
Subscribers
None
Projects
None
Description

[PM] Add a new "lazy" call graph analysis pass for the new pass manager.

The primary motivation for this pass is to separate the call graph
analysis used by the new pass manager's CGSCC pass management from the
existing call graph analysis pass. That analysis pass is (somewhat
unfortunately) over-constrained by the existing CallGraphSCCPassManager
requirements. Those requirements make it *really* hard to cleanly layer
the needed functionality for the new pass manager on top of the existing
analysis.

However, there are also a bunch of things that the pass manager would
specifically benefit from doing differently from the existing call graph
analysis, and this new implementation tries to address several of them:

  • Be lazy about scanning function definitions. The existing pass eagerly scans the entire module to build the initial graph. This new pass is significantly more lazy, and I plan to push this even further to maximize locality during CGSCC walks.
  • Don't use a single synthetic node to partition functions with an indirect call from functions whose address is taken. This node creates a huge choke-point which would preclude good parallelization across the fanout of the SCC graph when we got to the point of looking at such changes to LLVM.
  • Use a memory dense and lightweight representation of the call graph rather than value handles and tracking call instructions. This will require explicit update calls instead of some updates working transparently, but should end up being significantly more efficient. The explicit update calls ended up being needed in many cases for the existing call graph so we don't really lose anything.
  • Doesn't explicitly model SCCs and thus doesn't provide an "identity" for an SCC which is stable across updates. This is essential for the new pass manager to work correctly.
  • Only form the graph necessary for traversing all of the functions in an SCC friendly order. This is a much simpler graph structure and should be more memory dense. It does limit the ways in which it is appropriate to use this analysis. I wish I had a better name than "call graph". I've commented extensively this aspect.

This is still very much a WIP, in fact it is really just the initial
bits. But it is about the fourth version of the initial bits that I've
implemented with each of the others running into really frustrating
problms. This looks like it will actually work and I'd like to split the
actual complexity across commits for the sake of my reviewers. =] The
rest of the implementation along with lots of wiring will follow
somewhat more rapidly now that there is a good path forward.

Naturally, this doesn't impact any of the existing optimizer. This code
is specific to the new pass manager.

A bunch of thanks are deserved for the various folks that have helped
with the design of this, especially Nick Lewycky who actually sat with
me to go through the fundamentals of the final version here.

rL200903

llvm/trunk/include/llvm/Analysis/LazyCallGraph.h

Loading...

llvm/trunk/lib/Analysis/CMakeLists.txt

Loading...

llvm/trunk/lib/Analysis/LazyCallGraph.cpp

Loading...

llvm/trunk/test/Analysis/LazyCallGraph/

Loading...

llvm/trunk/test/Analysis/LazyCallGraph/basic.ll

Loading...

llvm/trunk/tools/opt/NewPMDriver.cpp

Loading...

llvm/trunk/tools/opt/Passes.cpp

Loading...

Add Comment