llvm/lib/IR/CMakeLists.txt
Chandler Carruth f348c9782c Introduce an AnalysisManager which is like a pass manager but with a lot
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194538 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-13 01:12:08 +00:00

53 lines
966 B
CMake

add_llvm_library(LLVMCore
AsmWriter.cpp
Attributes.cpp
AutoUpgrade.cpp
BasicBlock.cpp
ConstantFold.cpp
Constants.cpp
Core.cpp
DIBuilder.cpp
DataLayout.cpp
DebugInfo.cpp
DebugLoc.cpp
Dominators.cpp
Function.cpp
GCOV.cpp
GVMaterializer.cpp
Globals.cpp
IRBuilder.cpp
InlineAsm.cpp
Instruction.cpp
Instructions.cpp
IntrinsicInst.cpp
LLVMContext.cpp
LLVMContextImpl.cpp
LeakDetector.cpp
LegacyPassManager.cpp
Metadata.cpp
Module.cpp
Pass.cpp
PassManager.cpp
PassRegistry.cpp
PrintModulePass.cpp
Type.cpp
TypeFinder.cpp
Use.cpp
User.cpp
Value.cpp
ValueSymbolTable.cpp
ValueTypes.cpp
Verifier.cpp
)
# Workaround: It takes over 20 minutes to compile with msvc10.
# FIXME: Suppressing optimizations to core libraries would not be good thing.
if( MSVC_VERSION LESS 1700 )
set_property(
SOURCE Function.cpp
PROPERTY COMPILE_FLAGS "/Og-"
)
endif()
add_dependencies(LLVMCore intrinsics_gen)