search for: cgsccupdateresult

Dear all, I would like to use the PostDominatorTree in ArgPromotion. I did not find an example of how to use function level analysis inside CallGraphSCCPass. I tried to follow an example of how to use function-level pass in a module pass, but I hit "llvm_unreachable" in PMDataManager::addLowerLevelRequiredPass. What would be a proper way to make PostDominatorTree available in

...pipeline again (which should inline the devirtualized call) . The problem is scanning the initial SCC for indirect calls is not enough since inlining can produce indirect calls (which could then get devirtualized by later passes). One (ugly) fix is to pass the value handles to the inliner through CGSCCUpdateResult and let the inliner augment it as the caller gets indirect calls due to inlining. On Thu, Dec 7, 2017 at 12:20 PM, Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 12/07/2017 11:09 PM, Fedor Sergeev via llvm-dev wrote: > > Chandler et al, > > > > I h...

...c llvm::PassInfoMixin<MyCGSCCPass> { > public: > llvm::PreservedAnalyses run(llvm::LazyCallGraph::SCC &C, > llvm::CGSCCAnalysisManager &AM, > llvm::LazyCallGraph &CG, > llvm::CGSCCUpdateResult &UR) { > llvm::FunctionAnalysisManager &FAM = > AM.getResult<llvm::FunctionAnalysisManagerCGSCCProxy>(C, CG) > .getManager(); > for (llvm::LazyCallGraph::Node &N : C) { > llvm::Function &F = N.getFunction(); > llvm::Pos...

...k is made, coro-split is run and it adds an indirect call, coro-elide is run and it devirtualizes that call, and then another check is made. From the repeater pass's point of view, nothing has changed. This is something I'd like to tweak in future patches (my thinking is to add a member to CGSCCUpdateResult to allow passes to manually inform the pass manager about devirtualizations, but I'm very open to alternative ideas). But for now, I simply have Clang manually schedule two iterations of the coro-split pass, rather than have it rely on the repeater detecting a devirtualization and automatically...

Chandler et al, I have been playing with the new PM pipeline, being particularly interested in how it can handle devirtualization. Now, I discovered what I believe is a "regression" vs old PM on a rather simple one-translation-unit testcase. clang is able to devirtualize it with -O3 and fails to do so with -fexperimental-new-pass-manager added. It looks like a pipeline issue,

On 8/7/19 6:20 PM, Hiroshi Yamauchi wrote: > I basically run "clang > -fexperimental-new-pass-manager -print-after-all ..." > > It's conceivable that something is different in our setup or in clang > (from opt)... I'll see if I can reproduce it outside our setup. Does it depend on machine architecture? I generally use x86... regards,   Fedor. > > Thanks.