similar to: [LLVMdev] Getting CallGraph SCCs

Hey all, I'm working on adding function attribute propagation to function summaries in the ThinLTO index, and have run into some trouble with ensuring bottom-up traversal when finding the SCCs in the call graph. I'm basing my implementation for the GraphTraits for the ModuleSummaryIndex off the GraphTraits<CallGraph *> implementation (

I have a FunctionPass F that needs a list of all the SCCs for use in its doFinalization() method. Let's say I write a CallGraphSCCPass C that creates an array of all SCCs. Let C be required by F, and let F call getAnalysis<C>() from its doFinalization() method. Am I guaranteed that C's runOnSCC() method will have executed on all SCCs before F's doFinalization() method?

On 5/10/09, Török Edwin <edwintorok at gmail.com> wrote: > On 2009-05-10 20:11, Nick Johnson wrote: > > Hello, > > > > I'm writing a Function Pass. This function pass needs access to the > > CallGraph and CallGraph SCCs. Is there any way I can get CallGraph > > information without changing my pass to a CallGraphSCCPass ? > > > Does

Hello, I'm writing a Function Pass. This function pass needs access to the CallGraph and CallGraph SCCs. Is there any way I can get CallGraph information without changing my pass to a CallGraphSCCPass ? Thanks, -- Nick Johnson

On 2009-05-10 20:11, Nick Johnson wrote: > Hello, > > I'm writing a Function Pass. This function pass needs access to the > CallGraph and CallGraph SCCs. Is there any way I can get CallGraph > information without changing my pass to a CallGraphSCCPass ? Does getAnalysis<CallGraph>() work? But I'm not sure if using a FunctionPass to access Callgraph data is a good

I am trying to write a ModulePass which requires PostDominator sets for every function in the module. Now finding post dominators is a function pass. The link on the llvm.org website says that : "Currently it is illegal for a ModulePass<http://llvm.org/docs/WritingAnLLVMPass.html#ModulePass>to require a FunctionPass <http://llvm.org/docs/WritingAnLLVMPass.html#FunctionPass>.

On 2009-05-10 21:18, Nick Johnson wrote: > On 5/10/09, Török Edwin <edwintorok at gmail.com> wrote: > >> On 2009-05-10 20:11, Nick Johnson wrote: >> > Hello, >> > >> > I'm writing a Function Pass. This function pass needs access to the >> > CallGraph and CallGraph SCCs. Is there any way I can get CallGraph >> >

>>> Does getAnalysis<CallGraph>() work? Thanks Edwin, that works! What about the CallGraphSCC ? It looks like one can declare a CallGraphSCCPass, but I don't see any other way to get the SCCs of the call graph. -- Nick Johnson

Hi, I am using the scc_iterator class in my code on a CallGraph, where some functions are not called from within the module. It seems that scc_iterator does not list all SCCs if the graph is not connected; only those nodes connected to the node pointed to by GraphTraits<...>::getEntryNode() are returned. Can someone verify this behavior? Any tips on how I should go about extending the

On Sep 3, 2009, at 4:15 AM, Hans Vandierendonck wrote: Hi, > > I am using the scc_iterator class in my code on a CallGraph, where > some > functions are not called from within the module. It seems that > scc_iterator does not list all SCCs if the graph is not connected; > only > those nodes connected to the node pointed to by > GraphTraits<...>::getEntryNode() are

I printed the call graph as you suggested. The bugpoint bytecode that I sent below prints the following call graph: Indirect call node / | | \ / | | \ V | V V execute | prog_char clear_func | | V V push_constant | V Node0x8d7b370 i.e., Indirect call node -> execute

Hi all, I have one analysis pass that I want to perform on call graph SCCs. However, for each function in the SCC, I need function-level analyses, like the dominator tree and the memory dependency analysis. I’ve been told before <http://stackoverflow.com/questions/30059622/using-dominatortreewrapperpass-in-callgraphsccpass> that these were not available from a CallGraphSCCPass. What would

Hi Ryan, On 9/29/06, Ryan M. Lefever <lefever at crhc.uiuc.edu> wrote: > I have a FunctionPass F that needs a list of all the SCCs for use in its > doFinalization() method. Let's say I write a CallGraphSCCPass C that > creates an array of all SCCs. Let C be required by F, and let F call > getAnalysis<C>() from its doFinalization() method. Am I guaranteed that >

Thanks John. Does this solve the problem of analysis availability though? If I still have to run the function analyses manually, I might as well keep rolling with the CallGraphSCCPass. (I probably should have mentioned that this is what I’m using right now.) Félix > Le 2015-05-19 à 10:12:32, John Criswell <jtcriswel at gmail.com> a écrit : > > On 5/18/15 10:45 PM, Félix Cloutier

On Mon, Jan 2, 2017 at 2:24 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Davide, > > On Sat, Dec 31, 2016 at 4:19 AM, Davide Italiano <davide at freebsd.org> wrote: >> Although originally I wasn't, I'm increasingly convinced this is the >> right path forward (at least in the beginning), i.e. strip undef >> handling entirely. I tried

On Sep 29, 2006, at 2:05 PM, Domagoj Babic wrote: > > Check out scc_* iterators. Also note that the call graph > is not aware of the indirect calls, so you will need to write your > own CG implementation if you need to handle function pointers > soundly. > Chris, is this true? If so, it seems like a bad property for the CallGraphSCCPass framework. --Vikram

So I got very mixed results. With the CallGraphSCCPass, both `addRequired<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

Hi I see when LLVM builds the CallGraph SCCs. a function calling through a function pointer is conservatively assumed to call internal and external functions. Therefore, it has an edges pointing to the externalnode2, ie. the externalnode representing outgoing calls from this module. does LLVM have any function pointer analysis capabilities in the mainline ? Thanks, -Trent

On Fri, 29 Sep 2006, Vikram Adve wrote: > On Sep 29, 2006, at 2:05 PM, Domagoj Babic wrote: >> Check out scc_* iterators. Also note that the call graph >> is not aware of the indirect calls, so you will need to write your >> own CG implementation if you need to handle function pointers >> soundly. > Chris, is this true? If so, it seems like a bad property for the

I ran across an interesting case and wanted to share it. I'm not proposing any particular changes, but the experience seemed interesting to discuss. First, a bit of background. An LLVM Loop models a specific type of cycle in the CFG. Not all cycles are Loops. Many of our optimization transforms are phrased over loops, which means that a non-loop cycle tends to be less well optimized.