search for: scciter

...n behavior may impact things such as >> CallGraphSCCPass, GlobalsModRef, etc. and I don't know if it is >> desirable to have that change there. > > This definitely sounds bad, but doesn't match what I'm seeing with the > callgraphscc passmanager. How are you using SCCIterator? > > -Chris I have digged deeper into this; it seems everything is ok for CallGraphs. Here is what I found. Attached are 2 .ll files, reduced using bugpoint and a Pass that uses the SCCIterator to traverse the CallGraph SCCs. The pass simply prints all function names as it visits them....

...? The change in behavior may impact things such > as > CallGraphSCCPass, GlobalsModRef, etc. and I don't know if it is > desirable to have that change there. This definitely sounds bad, but doesn't match what I'm seeing with the callgraphscc passmanager. How are you using SCCIterator? -Chris

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

...du/mailman/listinfo/llvmdev > I'm not sure where specifically it might be useful in the codebase; I wrote it for use in an external (currently not public) project. I could just put it in the utility header for that project, but then it wouldn't be available to others, so I thought SCCIterator.h would be a better place. I figured people who'd be interested in detecting cycles might look in SCCIterator.h for a way to do so and find that code. It could also serve as an example of how to use scc_iterator, and, since it's a template, there's no penalty for having it in...

Hello, I posted an earlier version of this patch some months ago and realized I've still been sitting on it. The earlier version of this patch was rejected for adding a cycle detection function to SCCIterator.h. This function is now removed. This patch makes the following changes: 1. Allow SCCIterator to work with GraphT types that are constant. 2. Allow SCCIterator to work with inverse graphs. 3. Fix an incorrect comment in GraphTraits.h (the type in the comment was given as GraphType* when...

...the templates necessary to make it work with inverse graphs. I also added a "bb_reachable" function to tell whether an arbitrary graph node is part of cycle. Might this be useful to others? (Sorry for the double post; previous patch didn't compile.) --Patrick --- include/llvm/ADT/SCCIterator.h (revision 76093) +++ include/llvm/ADT/SCCIterator.h (working copy) @@ -194,6 +194,34 @@ return scc_iterator<T>::end(G); } +template <class T> +scc_iterator<Inverse<T> > scc_begin(Inverse<T> G) { + return scc_iterator<Inverse<T> >::...

...> > Hi Patrick, > > The scc_begin/end specializations look fine. The "bb_reachable" name > is not a good one though, it doesn't give any hint about what the > function actually does. I don't think it is really generally useful > enough to include in scciterator.h > > -Chris > I agree that bb_reachable is not the best name. How about "is_in_cycle" instead? I think a function to tell whether an arbitrary graph node is part of a cycle could be useful in a variety of circumstances; is there another header file where it would be...

...i Patrick, >> >> The scc_begin/end specializations look fine. The "bb_reachable" name >> is not a good one though, it doesn't give any hint about what the >> function actually does. I don't think it is really generally useful >> enough to include in scciterator.h >> >> -Chris >> > I agree that bb_reachable is not the best name. How about > "is_in_cycle" > instead? I think a function to tell whether an arbitrary graph node > is > part of a cycle could be useful in a variety of circumstances; is > th...

...> > I'm not sure where specifically it might be useful in the codebase; I > wrote it for use in an external (currently not public) project. I > could > just put it in the utility header for that project, but then it > wouldn't > be available to others, so I thought SCCIterator.h would be a better > place. I figured people who'd be interested in detecting cycles might > look in SCCIterator.h for a way to do so and find that code. It could > also serve as an example of how to use scc_iterator, and, since it's a > template, there's no penalty f...

...gt; Might this be useful to others? Hi Patrick, The scc_begin/end specializations look fine. The "bb_reachable" name is not a good one though, it doesn't give any hint about what the function actually does. I don't think it is really generally useful enough to include in scciterator.h -Chris > > > (Sorry for the double post; previous patch didn't compile.) > > --Patrick > > --- include/llvm/ADT/SCCIterator.h (revision 76093) > +++ include/llvm/ADT/SCCIterator.h (working copy) > @@ -194,6 +194,34 @@ > return scc_iterator<T&...

...a single object. It's the basic query > to decide if a function is part of a recursive computation (a cycle in > the call graph). CFGs happen to have special code for natural loops > but you could use this query to handle irreducible loops as well. These typically don't use the scciterator though. -Chris

Hi, I've been using scc_iterator, and I added the templates necessary to make it work with inverse graphs. I also added a "bb_reachable" function to tell whether an arbitrary graph node is part of cycle. Might this be useful to others? --Patrick --- include/llvm/ADT/SCCIterator.h (revision 76093) +++ include/llvm/ADT/SCCIterator.h (working copy) @@ -194,6 +194,34 @@ return scc_iterator<T>::end(G); } +template <class T> +scc_iterator<Inverse<T> > scc_begin(Inverse<T> G) { + return scc_iterator<Inverse<T> >:...

...ic query >> to decide if a function is part of a recursive computation (a cycle in >> the call graph). CFGs happen to have special code for natural loops >> but you could use this query to handle irreducible loops as well. >> > > These typically don't use the scciterator though. > > -Chris > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > Is there a better method for checking whether a basic b...

Hi, Is there any facility in LLVM to identify recursion in a call graph? I realize this is undecidable in the general case due to function pointers, but at least the static cases could be identified. I don't even care about whole-program recursion, just looking at a single module would suffice. But I don't see anything like this already in LLVM, so do I simply write some code to

...es could be identified. I don't > even care about whole-program recursion, just looking at a single > module would suffice. But I don't see anything like this already in > LLVM, so do I simply write some code to look for cycles in the call > graph? Thanks, use the facilities in SCCIterator.h, or declare your pass to be a CallGraphSCCPass in which case it will work one strongly connected component at a time. Ciao, Duncan.

>>> 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

On Oct 30, 2010, at 4:38 AM, Duncan Sands wrote: >> Is there any facility in LLVM to identify recursion in a call graph? ... > use the facilities in SCCIterator.h, or declare your pass to be a > CallGraphSCCPass in which case it will work one strongly connected > component at a time. Converting my ModulePass to a CallGraphSCCPass doesn't seem feasible, so I'll use llvm::scc_iterator. Here's what I have so far: bool MyModulePass::i...

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >

...elativePath="..\..\include\llvm\Adt\iterator"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Adt\PostOrderIterator.h"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Adt\SCCIterator.h"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Adt\SetOperations.h"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Adt\SetVector.h"> > > </File&gt...

...vm-2.8/include/llvm/ADT/PointerIntPair.h -- Installing: /usr/local/llvm-2.8/include/llvm/ADT/PointerUnion.h -- Installing: /usr/local/llvm-2.8/include/llvm/ADT/PostOrderIterator.h -- Installing: /usr/local/llvm-2.8/include/llvm/ADT/PriorityQueue.h -- Installing: /usr/local/llvm-2.8/include/llvm/ADT/SCCIterator.h -- Installing: /usr/local/llvm-2.8/include/llvm/ADT/STLExtras.h -- Installing: /usr/local/llvm-2.8/include/llvm/ADT/ScopedHashTable.h -- Installing: /usr/local/llvm-2.8/include/llvm/ADT/SetOperations.h -- Installing: /usr/local/llvm-2.8/include/llvm/ADT/SetVector.h -- Installing: /usr/local/l...