I have been recently working on my own custom pass manager for llvm passes (both off-the shelf and our custom passes). While working on it, I would like to retain the original pass manager interface (thus being able to schedule/run all existing passes) while making it more flexible and lightweight than the current “legacy pass manager”.
While working on it I have encountered several design issues that I would like to solve so that my code could be potentioally up-streamed to llvm comunity.
First one problem is that current AnalysisResolver class keeps reference for PMDataManager class which in turn contains some fields like InheritedAnalysis map, etc. which force pass manager design similar to current LegacyPassManager. Wouldn’t it be better to close member functions like findImplPass and findAnalysisPass into some abstract, interface-like class which would be required to be inherited by pass manager that we want to use for AnalysisResolver creation? Then AnalysisResolver could keep pointer to interface class.
Second problem I’ve encountered is that LoopPass takes LPPassManager reference argument inside doInitialization member function. I haven’t yet analyzed LoopPasses that are using this argument to check what do they use it for, but solution to make abstract interface like one I would like to make for AnalysisResolver would be applicable here. Also similar problem occurs with RegionPass and RGPassManager.
I heard there are some works on new pass manager for llvm I guess such changes could also be helpful for it.