mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-12-14 11:32:34 +00:00
d793a053ad
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
|
||
|---|---|---|
| .. | ||
| Argument.h | ||
| Attributes.h | ||
| BasicBlock.h | ||
| CallingConv.h | ||
| CMakeLists.txt | ||
| Constant.h | ||
| Constants.h | ||
| DataLayout.h | ||
| DerivedTypes.h | ||
| Function.h | ||
| GlobalAlias.h | ||
| GlobalValue.h | ||
| GlobalVariable.h | ||
| InlineAsm.h | ||
| InstrTypes.h | ||
| Instruction.def | ||
| Instruction.h | ||
| Instructions.h | ||
| IntrinsicInst.h | ||
| Intrinsics.h | ||
| Intrinsics.td | ||
| IntrinsicsAArch64.td | ||
| IntrinsicsARM.td | ||
| IntrinsicsHexagon.td | ||
| IntrinsicsMips.td | ||
| IntrinsicsNVVM.td | ||
| IntrinsicsPowerPC.td | ||
| IntrinsicsR600.td | ||
| IntrinsicsX86.td | ||
| IntrinsicsXCore.td | ||
| IRBuilder.h | ||
| LegacyPassManager.h | ||
| LegacyPassManagers.h | ||
| LLVMContext.h | ||
| MDBuilder.h | ||
| Metadata.h | ||
| Module.h | ||
| OperandTraits.h | ||
| Operator.h | ||
| PassManager.h | ||
| SymbolTableListTraits.h | ||
| Type.h | ||
| TypeBuilder.h | ||
| TypeFinder.h | ||
| Use.h | ||
| User.h | ||
| Value.h | ||
| ValueSymbolTable.h | ||