mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-07-22 09:29:31 +00:00
f348c9782c
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
53 lines
966 B
CMake
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)
|