search for: cgpassmanag

...00114e3 llvm::Function::CheckLazyArguments() const + 21 6 opt 0x000000010013a421 llvm::Function::arg_begin() + 21 7 LLVMRCI.dylib 0x0000000101483e02 (anonymous namespace)::RCI::runOnSCC(llvm::CallGraphSCC&) + 184 8 opt 0x0000000100205686 (anonymous namespace)::CGPassManager::RunPassOnSCC(llvm::Pass*, llvm::CallGraphSCC&, llvm::CallGraph&, bool&, bool&) + 230 9 opt 0x0000000100205abe (anonymous namespace)::CGPassManager::RunAllPassesOnSCC(llvm::CallGraphSCC&, llvm::CallGraph&, bool&) + 488 10 opt 0x000000010020...

...SCCPass that uses LoopInfo which is a FunctionPass. However, doing so results in the following error. **** Unable to schedule 'Natural Loop Information' required by '......' **** Google led me to this page, where Devang Patel suggests implementing the addLowerLevelRequiredPasses in CGPassManager in a manner similar to MPPassManager. http://old.nabble.com/DominatorTree-Information-required-in-CallGraphPass-td 21968640.html I tried this but to get analysis passes on the fly I need to use FunctionPassManagerImpl in CallGraphSCCPass.cpp which I cannot because it is not part of any header fi...

...p + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 18446744073707048303 4 LLVMHello.dylib 0x0002eba8 (anonymous namespace)::Hello::runOnSCC(std::vector<llvm::CallGraphNode*, std::allocator<llvm::CallGraphNode*> >&) + 24 5 libLLVM-2.7.dylib 0xe0cbff44 (anonymous namespace)::CGPassManager::RunPassOnSCC(llvm::Pass*, std::vector<llvm::CallGraphNode*, std::allocator<llvm::CallGraphNode*> >&, llvm::CallGraph&, bool&) + 340 6 libLLVM-2.7.dylib 0xe0cc07b2 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) + 770 7 libLLVM-2.7.dylib 0xe05...

...for a BasicBlockPass afaik). When reading the description of BasicBlockPass it seems to be legal to remove calls, and that should not impact the CFG, right? But it will impact the CallGraph. I believe that when the FunctionPass Manager is used from within the Call Graph SCC Pass Manager, then the CGPassManager will check the modification status from the FPManager and call RefreshCallGraph() (or set CallGraphUpToDate=false;) in case modification had been done. Thus, it seems to be legit for a FunctionPass (and thereby also the FunctionPassManager) to not always preserve the CallGraph. And I think this i...

...eline and splits the coroutine when it sees it the second time around. There are at least four different ways how I can request a restart of the pipeline, and I would like to solicit your advice on which one to pick. Option 1: Force revisit of the SCC if there are any coroutine in it. This makes CGPassManager aware of a coroutine attribute and keep restarting the pipeline until no functions in SCC has coroutine attribute on them. https://reviews.llvm.org/D21569 Option 2: Add a ref parameter bool& Devirt parameter to runSCC virtual method. If a pass sets Devirt to true, it indicates to CGPa...

...00114e3 llvm::Function::CheckLazyArguments() const + 21 6 opt 0x000000010013a421 llvm::Function::arg_begin() + 21 7 LLVMRCI.dylib 0x0000000101483e02 (anonymous namespace)::RCI::runOnSCC(llvm::CallGraphSCC&) + 184 8 opt 0x0000000100205686 (anonymous namespace)::CGPassManager::RunPassOnSCC(llvm::Pass*, llvm::CallGraphSCC&, llvm::CallGraph&, bool&, bool&) + 230 9 opt 0x0000000100205abe (anonymous namespace)::CGPassManager::RunAllPassesOnSCC(llvm::CallGraphSCC&, llvm::CallGraph&, bool&) + 488 10 opt 0x000000010020...

...ed<DominatorTreeWrapperPass>` and `addRequired<MemoryDependenceAnalysis>` fail at runtime. The LLVM core has just two CallGraphSCCPasses and neither uses neither analyses, so it's hard to find a valid example. I transformed the pass into a ModulePass, using scc_iterator as shown in CGPassManager to process functions in order, and the situation isn't a whole lot better. Interestingly, `addRequired<CallGraphWrapperPass>()` failed on me, even though at first glance, CGPassManager doesn't seem to be doing anything that I'm not doing. This is relatively easily bypassed by c...

...reading the description of BasicBlockPass it seems to be legal to > remove calls, and that should not impact the CFG, right? But it will impact > the CallGraph. > > > > I believe that when the FunctionPass Manager is used from within the Call > Graph SCC Pass Manager, then the CGPassManager will check the modification > status from the FPManager and call RefreshCallGraph() (or set > CallGraphUpToDate=false;) in case modification had been done. Thus, it seems > to be legit for a FunctionPass (and thereby also the FunctionPassManager) to > not always preserve the CallGraph...

...gt;> complex logic surrounding needing to run function passes nested within an >> SCC pass manager, while providing some guarantees about exactly what order >> the function passes are run. The existing CGSCC pass manager just punts on >> some of the problems that arise (look in CGPassManager::runOnModule, >> CGPassManager::RunAllPassesOnSCC, and CGPassManager::RunPassOnSCC in >> llvm/lib/Analysis/CallGraphSCCPass.cpp), and these are the problems that >> Chandler has been trying to solve. >> >> ( >> Why is this "function passes inside CGSCC pas...

...ockPass it seems to be legal to > > remove calls, and that should not impact the CFG, right? But it will impact > > the CallGraph. > > > > > > > > I believe that when the FunctionPass Manager is used from within the Call > > Graph SCC Pass Manager, then the CGPassManager will check the > modification > > status from the FPManager and call RefreshCallGraph() (or set > > CallGraphUpToDate=false;) in case modification had been done. Thus, it > seems > > to be legit for a FunctionPass (and thereby also the FunctionPassManager) > to > &gt...

...lex logic surrounding needing to run function passes nested within an >>> SCC pass manager, while providing some guarantees about exactly what order >>> the function passes are run. The existing CGSCC pass manager just punts on >>> some of the problems that arise (look in CGPassManager::runOnModule, >>> CGPassManager::RunAllPassesOnSCC, and CGPassManager::RunPassOnSCC in >>> llvm/lib/Analysis/CallGraphSCCPass.cpp), and these are the problems that >>> Chandler has been trying to solve. >>> >>> ( >>> Why is this "function...

...unction (this=0x10f3f10, __in_chrg=<value optimized out>) at /home/xchen/llvm/lib/VMCore/Function.cpp:188 #11 0x0000000000598107 in llvm::Inliner::runOnSCC (this=0x10e9780, SCC=...) at /home/xchen/llvm/lib/Transforms/IPO/Inliner.cpp:487 #12 0x000000000079a828 in (anonymous namespace)::CGPassManager::RunPassOnSCC (this=0x10e9f80, P=0x10e9780, CurSCC=..., CG=..., CallGraphUpToDate=@0x7fffffffd0af, DevirtualizedCall=@0x7fffffffd1f7) at /home/xchen/llvm/lib/Analysis/IPA/CallGraphSCCPass.cpp:121 #13 0x000000000079ac71 in (anonymous namespace)::CGPassManager::RunAllPassesOnSCC (this=0x10e...

...02ed44ff llvm::LPPassManager::runOnFunction(llvm::Function&) /home/dwmw2/git/llvm/lib/Analysis/LoopPass.cpp:204:0 #18 0x00000000035a1af1 llvm::FPPassManager::runOnFunction(llvm::Function&) /home/dwmw2/git/llvm/lib/IR/LegacyPassManager.cpp:1520:0 #19 0x0000000002e0311c (anonymous namespace)::CGPassManager::RunPassOnSCC(llvm::Pass*, llvm::CallGraphSCC&, llvm::CallGraph&, bool&, bool&) /home/dwmw2/git/llvm/lib/Analysis/CallGraphSCCPass.cpp:156:0 #20 0x0000000002e040a4 (anonymous namespace)::CGPassManager::RunAllPassesOnSCC(llvm::CallGraphSCC&, llvm::CallGraph&, bool&) /ho...

...described is the apparently quite complex logic surrounding needing to run function passes nested within an SCC pass manager, while providing some guarantees about exactly what order the function passes are run. The existing CGSCC pass manager just punts on some of the problems that arise (look in CGPassManager::runOnModule, CGPassManager::RunAllPassesOnSCC, and CGPassManager::RunPassOnSCC in llvm/lib/Analysis/CallGraphSCCPass.cpp), and these are the problems that Chandler has been trying to solve. ( Why is this "function passes inside CGSCC passes" stuff interesting? Because LLVM can do inli...

...I see > MyAnalysis > re-scheduled after MyModulePass3. > > It seems like the fact that MyAnalysis is not preserved by > MyCallGraphSCCPass > is somehow not propagated outside the Call Graph SCC Pass Manager. > > Is there something wrong with that sequence ? It is a bug. CGPassManager is incorrectly claiming that it is preserving all analysis info. - Devang > > > Thanks, > Julien > > -- > Julien Lerouge > PGP Key Id: 0xB1964A62 > PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62 > PGP Public Key from: keyserver.pgp.com > __...

...B.dylib 0xffffffff _sigtramp + 18446744073707048303 > 4 LLVMHello.dylib 0x0002eba8 (anonymous > namespace)::Hello::runOnSCC(std::vector<llvm::CallGraphNode*, > std::allocator<llvm::CallGraphNode*> >&) + 24 > 5 libLLVM-2.7.dylib 0xe0cbff44 (anonymous > namespace)::CGPassManager::RunPassOnSCC(llvm::Pass*, > std::vector<llvm::CallGraphNode*, std::allocator<llvm::CallGraphNode*> > >&, llvm::CallGraph&, bool&) + 340 > 6 libLLVM-2.7.dylib 0xe0cc07b2 (anonymous > namespace)::CGPassManager::runOnModule(llvm::Module&) + 770 > 7 lib...

...; remove calls, and that should not impact the CFG, right? But it will > impact > > > the CallGraph. > > > > > > > > > > > > I believe that when the FunctionPass Manager is used from within the > Call > > > Graph SCC Pass Manager, then the CGPassManager will check the > > modification > > > status from the FPManager and call RefreshCallGraph() (or set > > > CallGraphUpToDate=false;) in case modification had been done. Thus, it > > seems > > > to be legit for a FunctionPass (and thereby also the > Functio...

I've landed the patch in r324449. Before we merge this into two different Clang release branches and almost immediately release one of them, I would really like someone to confirm that this patch works well with the Linux kernel. David, if you're up for that, it would be great. Alternatively, Guenter or someone else here can help. On Tue, Feb 6, 2018 at 5:59 PM Chandler Carruth

...after inlining is done for a node, the BFI info will be explicitly >> invalidated for that node due to the function passes run later by SCC >> pass manager. This is expected. > > Just to make sure, you're aware this will cost at least one re-computation > per iteration in CGPassManager::runOnModule right? If that's expected and > acceptable, then yes, the approach you seem to be describing should be > workable. > For each leaf node, the number of BFI computation is <= 1. For other nodes, it is <=2 (one as caller, one as callee) -- in other words, it is linea...

...tly quite > complex logic surrounding needing to run function passes nested > within an SCC pass manager, while providing some guarantees about > exactly what order the function passes are run. The existing CGSCC > pass manager just punts on some of the problems that arise (look in > CGPassManager::runOnModule, CGPassManager::RunAllPassesOnSCC, and > CGPassManager::RunPassOnSCC in > llvm/lib/Analysis/CallGraphSCCPass.cpp), and these are the problems > that Chandler has been trying to solve. > ( > Why is this "function passes inside CGSCC passes" stuff interesting?...