hanchenye-llvm-project/llvm/lib/IR/CMakeLists.txt

48 lines
795 B
CMake
Raw Normal View History

add_llvm_library(LLVMCore
AsmWriter.cpp
Attributes.cpp
AutoUpgrade.cpp
BasicBlock.cpp
ConstantFold.cpp
ConstantRange.cpp
Constants.cpp
Core.cpp
DiagnosticInfo.cpp
DiagnosticPrinter.cpp
DIBuilder.cpp
DataLayout.cpp
DebugInfo.cpp
2011-10-05 02:22:24 +08:00
DebugLoc.cpp
Dominators.cpp
Function.cpp
2011-10-05 02:22:24 +08:00
GCOV.cpp
2010-01-28 04:44:12 +08:00
GVMaterializer.cpp
Globals.cpp
2010-01-28 04:44:12 +08:00
IRBuilder.cpp
IRPrintingPasses.cpp
InlineAsm.cpp
Instruction.cpp
Instructions.cpp
IntrinsicInst.cpp
LLVMContext.cpp
LLVMContextImpl.cpp
LeakDetector.cpp
LegacyPassManager.cpp
Mangler.cpp
Metadata.cpp
Module.cpp
Pass.cpp
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. llvm-svn: 194538
2013-11-13 09:12:08 +08:00
PassManager.cpp
PassRegistry.cpp
Type.cpp
TypeFinder.cpp
Use.cpp
User.cpp
Value.cpp
ValueSymbolTable.cpp
ValueTypes.cpp
Verifier.cpp
)
add_dependencies(LLVMCore intrinsics_gen)