search for: lazycallgraph

...nd easy (my thanks to > those involved -- the design is great!). However, I'm struggling with > 'coro-split', which is an SCC pass. Specifically, I'd like advice on > how to appropriately update the new pass manager's preferred > representation of the SCC: 'llvm::LazyCallGraph'. > > Before I ask my specific questions about 'LazyCallGraph', it may help > to explain my understanding of the 'coro-split' pass and how it > modifies the call graph: > > The coro-split pass "clones" coroutine functions. For example, for a > coro...

...LLVM does. > This incremental simplification is an important feature of our inliner, and one we should endeavor to keep. We might also want different phases at some point (e.g. a top-down and a bottom-up phase), but that's another story. > ) > > As background for what is below, the LazyCallGraph tracks two graphs: the "call graph" and the "ref graph". > Conceptually, the call graph is the graph of direct calls, where indirect calls and calls to external functions do not appear (or are connected to dummy nodes). The ref graph is basically the graph of all functions t...

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

...s early inlining on >> the entire module, then does simplifications on the entire module, then >> does late inlining on the entire module; so it is not able to incrementally >> simplify as it inlines like LLVM does. >> ) >> >> As background for what is below, the LazyCallGraph tracks two graphs: the >> "call graph" and the "ref graph". >> Conceptually, the call graph is the graph of direct calls, where indirect >> calls and calls to external functions do not appear (or are connected to >> dummy nodes). The ref graph is basicall...

...es like LLVM does. This incremental simplification is an important feature of our inliner, and one we should endeavor to keep. We might also want different phases at some point (e.g. a top-down and a bottom-up phase), but that's another story. > ) > As background for what is below, the LazyCallGraph tracks two graphs: > the "call graph" and the "ref graph". > Conceptually, the call graph is the graph of direct calls, where > indirect calls and calls to external functions do not appear (or are > connected to dummy nodes). The ref graph is basically the graph of &...

Hello, GCC 9.0 introduces a new warning checkers and some of them found possible issues in LLVM. In file included from /home/davidbolvansky/trunk/llvm/include/llvm/Analysis/LazyCallGraph.h:38, from /home/davidbolvansky/trunk/llvm/unittests/Analysis/LazyCallGraphTest.cpp:10: /home/davidbolvansky/trunk/llvm/include/llvm/ADT/ArrayRef.h: In instantiation of ‘llvm::ArrayRef<T>::ArrayRef(const std::initializer_list<_Tp>&) [with T = llvm::LazyCallGraph::No...

...es different inlining "phases"; e.g. it does early inlining on the entire module, then does simplifications on the entire module, then does late inlining on the entire module; so it is not able to incrementally simplify as it inlines like LLVM does. ) As background for what is below, the LazyCallGraph tracks two graphs: the "call graph" and the "ref graph". Conceptually, the call graph is the graph of direct calls, where indirect calls and calls to external functions do not appear (or are connected to dummy nodes). The ref graph is basically the graph of all functions transit...

...plification is an important feature of our inliner, and one we should endeavor to keep. We might also want different phases at some point (e.g. a top-down and a bottom-up phase), but that's another story. >>> >>> ) >>> >>> As background for what is below, the LazyCallGraph tracks two graphs: the "call graph" and the "ref graph". >>> Conceptually, the call graph is the graph of direct calls, where indirect calls and calls to external functions do not appear (or are connected to dummy nodes). The ref graph is basically the graph of all func...

...s early inlining on >> the entire module, then does simplifications on the entire module, then >> does late inlining on the entire module; so it is not able to incrementally >> simplify as it inlines like LLVM does. >> ) >> >> As background for what is below, the LazyCallGraph tracks two graphs: the >> "call graph" and the "ref graph". >> Conceptually, the call graph is the graph of direct calls, where indirect >> calls and calls to external functions do not appear (or are connected to >> dummy nodes). The ref graph is basicall...

...:FunctionAnalysisManagerCGSCCProxy', which allows you to access > function analyses from within an CGSCC pass. Here's an example of > using it: > > ``` > class MyCGSCCPass : public 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<ll...

...>> the entire module, then does simplifications on the entire module, then >>> does late inlining on the entire module; so it is not able to incrementally >>> simplify as it inlines like LLVM does. >>> ) >>> >>> As background for what is below, the LazyCallGraph tracks two graphs: >>> the "call graph" and the "ref graph". >>> Conceptually, the call graph is the graph of direct calls, where >>> indirect calls and calls to external functions do not appear (or are >>> connected to dummy nodes). The ref g...

...;>> > have already been visited? Currently I don't think it can, and IIRC >>>>> from the >>>>> > discussion at the social this is one thing that Chandler is hoping >>>>> to fix. >>>>> > The "ref edge" notion in LazyCallGraph ensures that we cannot create >>>>> a call >>>>> > edge (devirtualizing a ref edge) that will point at an SCC that has >>>>> not yet >>>>> > been visited. >>>>> > >>>>> > E.g. consider this graph:...

...being >>> visited) >>> > have already been visited? Currently I don't think it can, and IIRC >>> from the >>> > discussion at the social this is one thing that Chandler is hoping to >>> fix. >>> > The "ref edge" notion in LazyCallGraph ensures that we cannot create a >>> call >>> > edge (devirtualizing a ref edge) that will point at an SCC that has >>> not yet >>> > been visited. >>> > >>> > E.g. consider this graph: >>> > >>> > digraph G {...

...module, then does simplifications on the entire >>>> module, then does late inlining on the entire module; so it is not able to >>>> incrementally simplify as it inlines like LLVM does. >>>> ) >>>> >>>> As background for what is below, the LazyCallGraph tracks two graphs: >>>> the "call graph" and the "ref graph". >>>> Conceptually, the call graph is the graph of direct calls, where >>>> indirect calls and calls to external functions do not appear (or are >>>> connected to dummy n...

...entire >>>>>> module, then does late inlining on the entire module; so it is not able to >>>>>> incrementally simplify as it inlines like LLVM does. >>>>>> ) >>>>>> >>>>>> As background for what is below, the LazyCallGraph tracks two graphs: >>>>>> the "call graph" and the "ref graph". >>>>>> Conceptually, the call graph is the graph of direct calls, where >>>>>> indirect calls and calls to external functions do not appear (or are >>>&...

...r to keep. We might also want different > phases at > >>> some point (e.g. a top-down and a bottom-up phase), but that's another > >>> story. > >>>> > >>>> ) > >>>> > >>>> As background for what is below, the LazyCallGraph tracks two graphs: > >>>> the "call graph" and the "ref graph". > >>>> Conceptually, the call graph is the graph of direct calls, where > >>>> indirect calls and calls to external functions do not appear (or are > >>>>...

...visited? Currently I don't think it can, and >>>>>>> IIRC from the >>>>>>> > discussion at the social this is one thing that Chandler is hoping >>>>>>> to fix. >>>>>>> > The "ref edge" notion in LazyCallGraph ensures that we cannot >>>>>>> create a call >>>>>>> > edge (devirtualizing a ref edge) that will point at an SCC that >>>>>>> has not yet >>>>>>> > been visited. >>>>>>> > >>>...

...an reach via direct calls emanating from the SCC being > visited) > > have already been visited? Currently I don't think it can, and IIRC from > the > > discussion at the social this is one thing that Chandler is hoping to > fix. > > The "ref edge" notion in LazyCallGraph ensures that we cannot create a > call > > edge (devirtualizing a ref edge) that will point at an SCC that has not > yet > > been visited. > > > > E.g. consider this graph: > > > > digraph G { > > A -> B; B -> A; // SCC {A,B} > > S -&g...

...f, label %bb4, label %bb1 bb1: %tmp2 = load { i8* }*, { i8* }** %tmp, align 8 %tmp3 = call i8* @access({ i8* }* %tmp2, i64 undef) br label %bb4 bb4: ret i8* undef } This IR, if compiled with `opt -passes='cgscc(inline,argpromotion)' -disable-output` hits a bunch of asserts in the LazyCallGraph. The problem here is that `argpromotion` turns a normal looking function `i8* @access({ i8* }* %arg, i64)` and turn it into a magical function `i8* @access(i8* %arg, i64)`. This latter signature is the POSIX `access` function that LLVM's `TargetLibraryInfo` knows magical things about. Because...

...unctionPassAdaptor is a module transformation pass that contains a FunctionPassManager (with some set of function passes). - AnalysisManagers interoperate via proxies. E.g., FunctionAnalysisManagerModuleProxy is a module analysis pass that forwards to a FunctionAnalysisManager. - LazyCallGraph and ModuleToPostOrderCGSCCPassAdaptor collude to visit SCCs in post-order, including API for updating the SCC-graph on-the-fly without invalidating the traversal. I think what's done generally looks great. In particular, the declarative syntax is awesome and it's a huge step to ha...