search for: irunitt

...mod_manager = ModuleAnalysisManager { }; PB.registerModuleAnalyses(mod_manager); AAResults& AAR = mod_manager.getResult<AAManager>(*M); But the code fails at .getResult with the following error: /llvm/include/llvm/IR/PassManager.h:778: typename PassT::Result& llvm::AnalysisManager<IRUnitT, ExtraArgTs>::getResult(IRUnitT&, ExtraArgTs ...) [with PassT = llvm::AAManager; IRUnitT = llvm::Module; ExtraArgTs = {}; typename PassT::Result = llvm::AAResults]: Assertion `AnalysisPasses.count(PassT::ID()) && "This analysis pass was not registered prior to being queried&quot...

Hi Philip, Thanks for the response. Under llvm-5.0.2 and llvm-6.0.1 in Debug mode, the crash hit at the same assertion: /usr/local/include/llvm/IR/PassManager.h:689: typename PassT::Result& llvm::AnalysisManager<IRUnitT, ExtraArgTs>::getResult(IRUnitT&, ExtraArgTs ...) [with PassT = llvm::InnerAnalysisManagerProxy<llvm::AnalysisManager<llvm::Loop, llvm::LoopStandardAnalysisResults&>, llvm::Function>; IRUnitT = llvm::Function; ExtraArgTs = {}; typename PassT::Result = llvm::InnerAnalysisManag...

...do so. Not sure the best way. We can't just iterate over all the functions calling `invalidate`; a module pass may have e.g. deleted a function, so we would never call `invalidate` on the deleted function. A simple solution is to add another member to the analysis manager which tracks, for each IRUnitT, all IRUnit's that we have state cached for (so we can easily walk them). Interestingly, it seems like the current state in trunk is that a module analysis can't preserve a specific function analysis. The only way that analysis invalidation can propagate downwards is by clearing the entire...

...can accept any IRUnit. The advantage of this is that it is source compatible with all the existing code using multiple manager, proxies, etc. The code on my branch at least passes check-llvm. But of course the existing code doesn't test any of the situations where being able to handle multiple IRUnitT's in a single analysis manager would matter. Tomorrow, I get to churn all the passes that have been ported so far, removing the proxies etc. Another thing that just came to me: the current way things work with adaptors means that if a function transformation invalidates a module analysis,...

...best way. We can't > just iterate over all the functions calling `invalidate`; a module pass may > have e.g. deleted a function, so we would never call `invalidate` on the > deleted function. A simple solution is to add another member to the > analysis manager which tracks, for each IRUnitT, all IRUnit's that we have > state cached for (so we can easily walk them). > > Interestingly, it seems like the current state in trunk is that a module > analysis can't preserve a specific function analysis. The only way that > analysis invalidation can propagate downwards i...

...Ptr->getType(), valuePtr, index )`... would that be correct? `arg_iterator` no longer converst to Value*, I have a lot of this now: &*(args++) This seems like I'm doing something wrong. Is there a more correct way to convert to the `Value*`? `PassManager` is now a tample type with `IRUnitT`. What is the `IRUnitT` type? Or rather, how should I be creating the `PassManager`? Why does `EngineBuilder` require a `unique_ptr` for the `Module` now? After I create the builder I still need to reference the module, in particular to run the pass manager and look up functions to run. Same for `...

...use we could make the analysis reacquire the >> pointer at the start of every query. Holding SCEV* is the problem. >> > > Looks like SCEV* at least is held only by LoopAccessInfo. (Looks like LAA > holds Loop* too) > Note that Loop (and SCC) are somewhat special as they are IRUnitTs and might as a consequence be more reasonable to hold on to and expect definitive invalidation to occur. But I say "might". I think this will be case-by-case depending on how they're being used. > New updated rendering at http://reviews.llvm.org/F2161258 > (DependenceAnalysis...

...ntal problem because we could make the analysis reacquire the pointer at the start of every query. Holding SCEV* is the problem. > > Looks like SCEV* at least is held only by LoopAccessInfo. (Looks like LAA holds Loop* too) > > Note that Loop (and SCC) are somewhat special as they are IRUnitTs and might as a consequence be more reasonable to hold on to and expect definitive invalidation to occur. But I say "might". I think this will be case-by-case depending on how they're being used. > > New updated rendering at http://reviews.llvm.org/F2161258 <http://reviews....

...in place. > > I'll start working on fixing the analysis managers. There seem to > basically be two parts (although they may need to be done simultaneously to > make sure all the pieces fit together): > - unify all the analysis managers into a single analysis manager for all > IRUnitT's (requires type-erasing the IRUnit) > - introduce the dependency tracking machinery > > I think I gave a reasonable outline in the two posts above: > - the one starting with "To clarify, it seems like the current new PM is > essentially trying to solve the problem of mainta...

...tion::run(Function &F, AnalysisManager AM) { > // Must be called before getting analyses, as it might invalidate some. > canonicalizeIR<LCSSA>(F, AM); > > ... > } > > > include/IR/Canonicalization.h: > > template <typename CanonicalizationT, typename IRUnitT> > void canonicalizeIR(IRUnitT &IR, AnalysisManager &AM) { > using IndicatorT = typename CanonicalizationT::IndicatorAnalysis; > if (AM.getCachedResult<http://AM.getCachedResult><IndicatorT>(IR)) > return; > CanonicalizationT C; > PreservedAnalys...

This question has been submitted to stackoverflow (https://stackoverflow.com/questions/51934964/function-optimization-pass) but someone suggested me that it should be submitted to llvm-dev mailing list instead. I'm sorry for the duplication. I am trying to use PassBulider and FunctionPassManager || to optimize a function in a module, what I have done is: mod = ...load module from LLVM

...A.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. I'm actually not quite sure that that will even work. Once I have test-suite fully building successfully with the LTO pipeline in the new PM I'll be able to give a more confident answer (esp. w.r.t. the manager for different IRUnitT's). But at this point I'm not confident running *any* pass pipeline in the new PM without at least assertions+ASan. We may want to have a proper design discussion around this problem though. Also I'd like to have test-suite working (by hook or by crook) with LTO in the new PM so we ca...

...o do `Foo::setPreserved(PA);`. >> I'm actually not quite sure that that will even work. Once I have >> test-suite fully building successfully with the LTO pipeline in the new PM >> I'll be able to give a more confident answer (esp. w.r.t. the manager for >> different IRUnitT's). >> But at this point I'm not confident running *any* pass pipeline in the >> new PM without at least assertions+ASan. >> >> We may want to have a proper design discussion around this problem though. >> >> Also I'd like to have test-suite working (...

...nalyses, as it might invalidate >> some. >> > canonicalizeIR<LCSSA>(F, AM); >> > >> > ... >> > } >> > >> > >> > include/IR/Canonicalization.h: >> > >> > template <typename CanonicalizationT, typename IRUnitT> >> > void canonicalizeIR(IRUnitT &IR, AnalysisManager &AM) { >> > using IndicatorT = typename CanonicalizationT::IndicatorAnalysis; >> > if (AM.getCachedResult<IndicatorT>(IR)) >> > return; >> > CanonicalizationT C; >> &...

...> in place. > I'll start working on fixing the analysis managers. There seem to > basically be two parts (although they may need to be done > simultaneously to make sure all the pieces fit together): > - unify all the analysis managers into a single analysis manager for > all IRUnitT's (requires type-erasing the IRUnit) > - introduce the dependency tracking machinery > I think I gave a reasonable outline in the two posts above: > - the one starting with " To clarify, it seems like the current new > PM is essentially trying to solve the problem of > main...

...understand the problem, this is a fully-general solution. I > > see > > no reason not to have a fully-general solution. > > Yeah, the mechanics of maintaining this fully general mapping are > straightforward in the abstract (once we have a single analysis > manager for all IRUnitT's). Essentially, the analysis manager > maintains a stack of ( Analysis, IRUnit) that it is currently > computing and pushes/pops the stack as it (re-)enters/exits > get{,Cached}Result. If the stack is not empty (suppose top of stack > is `(AnalysisFoo, IRUnitBar)`), then when we go...

...ved(PA);`. > > > I'm actually not quite sure that that will even work. Once I have > > test-suite fully building successfully with the LTO pipeline in the > > new PM I'll be able to give a more confident answer (esp. w.r.t. > > the > > manager for different IRUnitT's). > > > But at this point I'm not confident running *any* pass pipeline in > > the new PM without at least assertions+ASan. > > > We may want to have a proper design discussion around this problem > > though. > > > Also I'd like to have test...

...s I understand the problem, this is a fully-general solution. I see no >> reason not to have a fully-general solution. >> > > Yeah, the mechanics of maintaining this fully general mapping are > straightforward in the abstract (once we have a single analysis manager for > all IRUnitT's). Essentially, the analysis manager maintains a stack of (Analysis, > IRUnit) that it is currently computing and pushes/pops the stack as it > (re-)enters/exits get{,Cached}Result. If the stack is not empty (suppose > top of stack is `(AnalysisFoo, IRUnitBar)`), then when we go to pu...

...em, this is a fully-general solution. I see no >>> reason not to have a fully-general solution. >>> >> >> Yeah, the mechanics of maintaining this fully general mapping are >> straightforward in the abstract (once we have a single analysis manager for >> all IRUnitT's). Essentially, the analysis manager maintains a stack of (Analysis, >> IRUnit) that it is currently computing and pushes/pops the stack as it >> (re-)enters/exits get{,Cached}Result. If the stack is not empty (suppose >> top of stack is `(AnalysisFoo, IRUnitBar)`), then when...

...; > > have > > > > test-suite fully building successfully with the LTO pipeline in > > > > the > > > > new PM I'll be able to give a more confident answer (esp. > > > > w.r.t. > > > > the > > > > manager for different IRUnitT's). > > > > > > > > > > But at this point I'm not confident running *any* pass pipeline > > > > in > > > > the new PM without at least assertions+ASan. > > > > > > > > > > We may want to have a proper...