more smarts in it. This is where most of the interesting logic that used
to live in the implicit-scheduling-hackery of the old pass manager will
live.

Like the previous commits, note that this is a very early prototype!
I expect substantial changes before this is ready to use.

The core of the design is the following:

- We have an AnalysisManager which can be used across a series of
  passes over a module.
- The code setting up a pass pipeline registers the analyses available
  with the manager.
- Individual transform passes can check than an analysis manager
  provides the analyses they require in order to fail-fast.
- There is *no* implicit registration or scheduling.
- Analysis passes are different from other passes: they produce an
  analysis result that is cached and made available via the analysis
  manager.
- Cached results are invalidated automatically by the pass managers.
- When a transform pass requests an analysis result, either the analysis
  is run to produce the result or a cached result is provided.

There are a few aspects of this design that I *know* will change in
subsequent commits:
- Currently there is no "preservation" system, that needs to be added.
- All of the analysis management should move up to the analysis library.
- The analysis management needs to support at least SCC passes. Maybe
  loop passes. Living in the analysis library will facilitate this.
- Need support for analyses which are *both* module and function passes.
- Need support for pro-actively running module analyses to have cached
  results within a function pass manager.
- Need a clear design for "immutable" passes.
- Need support for requesting cached results when available and not
  re-running the pass even if that would be necessary.
- Need more thorough testing of all of this infrastructure.

There are other aspects that I view as open questions I'm hoping to
resolve as I iterate a bit on the infrastructure, and especially as
I start writing actual passes against this.
- Should we have separate management layers for function, module, and
  SCC analyses? I think "yes", but I'm not yet ready to switch the code.
  Adding SCC support will likely resolve this definitively.
- How should the 'require' functionality work? Should *that* be the only
  way to request results to ensure that passes always require things?
- How should preservation work?
- Probably some other things I'm forgetting. =]

Look forward to more patches in shorter order now that this is in place.

llvm-svn: 194538

give the files a legacy prefix in the right directory. Use forwarding
headers in the old locations to paper over the name change for most
clients during the transitional period.

No functionality changed here! This is just clearing some space to
reduce renaming churn later on with a new system.

Even when the new stuff starts to go in, it is going to be hidden behind
a flag and off-by-default as it is still WIP and under development.

This patch is specifically designed so that very little out-of-tree code
has to change. I'm going to work as hard as I can to keep that the case.
Only direct forward declarations of the PassManager class are impacted
by this change.

llvm-svn: 194324

Working on a better solution to this.

This reverts commit 7d4e9934e7ca83094c5cf41346966c8350179ff2.

llvm-svn: 190990

This puts all the global PassManager debugging flags, like
-print-after-all and -time-passes, behind a managed static. This
eliminates their static initializers and, more importantly, exit-time
destructors.

The only behavioral change I anticipate is that tools need to
initialize the PassManager before parsing the command line in order to
export these options, which makes sense. Tools that already initialize
the standard passes (opt/llc) don't need to do anything new.

llvm-svn: 190974

llvm-svn: 190973

Use SmallVectorImpl::iterator/const_iterator instead of SmallVector to avoid specifying the vector size.

llvm-svn: 185540

Patch by Robert Wilhelm.

llvm-svn: 181138

llvm-svn: 178662

Use a DenseMap instead of a std::map for AnalysisID -> Pass* maps. This reduces the pass-manager overhead from FPPassManager::runOnFunction() by about 10%.

llvm-svn: 176072

llvm-svn: 174492

into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.

I'll be updating other docs and other files in smaller subsequnet
commits.

While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.

Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)

llvm-svn: 171359

- Added calls to doInitialization/doFinalization to immutable passes
- fixed ordering of calls to doFinalization to be the reverse of the pass run order due to potential dependencies
- fixed machine module info to operate in the doInitialization/doFinalization model, also fixes some FIXMEs

reviewed by Evan Cheng <evan.cheng@apple.com>

llvm-svn: 169391

moves doInitialization and doFinalization to the Pass class and removes some unreachable code in MachineModuleInfo

reviewed by Evan Cheng <evan.cheng@apple.com>

llvm-svn: 169164

llvm-svn: 169134

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

llvm-svn: 169083

This avoids unidentified duplicates in the pass execution time report
when a pass runs more than once in the pass manager pipeline.

llvm-svn: 169039

start up and clean up module passes, now that ASAN and TSAN are fixed the
tests pass

llvm-svn: 168905

Revert r168635 "Step towards implementation of pass manager with doInitialization and doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model".
It appears to have broken at least one buildbot.

llvm-svn: 168654

Step towards implementation of pass manager with doInitialization and doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model

Patch by Pedro Artigas, with feedback from by Chandler Carruth.

llvm-svn: 168635

The bug can be triggered when we require LoopInfo analysis ahead of DominatorTree construction in a Module Pass. The cause is that the LoopInfo analysis itself also invokes DominatorTree construction, therefore, when PassManager schedules LoopInfo, it will add DominatorTree first. Then after that, when the PassManger turns to schedule DominatorTree invoked by the above ModulePass, it finds there is already a DominatorTree, so it delete the redundant one. However, somehow it still try to access that pass pointer after free as code pasted below, which results in segment fault.

llvm-svn: 168581

llvm-svn: 168049

Add doInitialization and doFinalization methods to ModulePass's, to allow them to be re-initialized and reused on multiple Module's.

Patch by Pedro Artigas.

llvm-svn: 168008

llvm-svn: 167809

getNumContainedPasses() used to compute the size of the vector on demand. It is
called repeated in loops (such as runOnFunction()) and it can be updated while
inside the loop.

llvm-svn: 167759

Revert 'Fix a typo 'iff' => 'if''. iff is an abreviation of if and only if. See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767

llvm-svn: 164768

llvm-svn: 164767

llvm-svn: 163258

llvm-svn: 160446

llvm-svn: 156755

the PassManager annoying and should be reimplemented as a decorator
on top of existing passes (as should the timing data).

llvm-svn: 153305

llvm-svn: 149849

The pass pointer should never be referenced after sending it to
schedulePass(), which may delete the pass. To fix this bug I had to
clean up the design leading to more goodness.

You may notice now that any non-analysis pass is printed. So things like loop-simplify and lcssa show up, while target lib, target data, alias analysis do not show up. Normally, analysis don't mutate the IR, but you can now check this by using both -print-after and -print-before. The effects of analysis will now show up in between the two.

The llc path is still in bad shape. But I'll be improving it in my next checkin. Meanwhile, print-machineinstrs still works the same way. With print-before/after, many llc passes that were not printed before now are, some of these should be converted to analysis. A few very important passes, isel and scheduler, are not properly initialized, so not printed.

llvm-svn: 149480

llvm-svn: 146960

While at it, merge some format strings.

llvm-svn: 142140

llvm-svn: 139642

llvm-svn: 138749

llvm-svn: 138748

Patch by Xiaoyi Guo!

llvm-svn: 138737