mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-11-02 07:11:49 +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 |
||
---|---|---|
.. | ||
AsmWriter.cpp | ||
AsmWriter.h | ||
AttributeImpl.h | ||
Attributes.cpp | ||
AutoUpgrade.cpp | ||
BasicBlock.cpp | ||
CMakeLists.txt | ||
ConstantFold.cpp | ||
ConstantFold.h | ||
Constants.cpp | ||
ConstantsContext.h | ||
Core.cpp | ||
DataLayout.cpp | ||
DebugInfo.cpp | ||
DebugLoc.cpp | ||
DIBuilder.cpp | ||
Dominators.cpp | ||
Function.cpp | ||
GCOV.cpp | ||
Globals.cpp | ||
GVMaterializer.cpp | ||
InlineAsm.cpp | ||
Instruction.cpp | ||
Instructions.cpp | ||
IntrinsicInst.cpp | ||
IRBuilder.cpp | ||
LeakDetector.cpp | ||
LeaksContext.h | ||
LegacyPassManager.cpp | ||
LLVMBuild.txt | ||
LLVMContext.cpp | ||
LLVMContextImpl.cpp | ||
LLVMContextImpl.h | ||
Makefile | ||
Metadata.cpp | ||
Module.cpp | ||
Pass.cpp | ||
PassManager.cpp | ||
PassRegistry.cpp | ||
PrintModulePass.cpp | ||
SymbolTableListTraitsImpl.h | ||
Type.cpp | ||
TypeFinder.cpp | ||
Use.cpp | ||
User.cpp | ||
Value.cpp | ||
ValueSymbolTable.cpp | ||
ValueTypes.cpp | ||
Verifier.cpp |