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
..
AttributesTest.cpp
CMakeLists.txt	[PM] Start sketching out the new module and function pass manager.	2013-11-09 13:09:08 +00:00
ConstantsTest.cpp
DominatorTreeTest.cpp
InstructionsTest.cpp
IRBuilderTest.cpp
LegacyPassManagerTest.cpp	Move the old pass manager infrastructure into a legacy namespace and	2013-11-09 12:26:54 +00:00
Makefile
MDBuilderTest.cpp
MetadataTest.cpp
PassManagerTest.cpp	Introduce an AnalysisManager which is like a pass manager but with a lot	2013-11-13 01:12:08 +00:00
PatternMatch.cpp
TypeBuilderTest.cpp
TypesTest.cpp
ValueMapTest.cpp
ValueTest.cpp
VerifierTest.cpp	Add calls to doInitialization() and doFinalization() in verifyFunction()	2013-10-30 22:37:51 +00:00
WaymarkTest.cpp