similar to: [LLVMdev] graph abstraction proposal

On Thu, Apr 8, 2010 at 2:10 AM, Jochen Wilhelmy <j.wilhelmy at arcor.de> wrote: > Hi! > > while trying to use llvm::DominatorTreeBase on a custom graph that > has nothing to do with llvm::BasicBlock I ran into some difficulties, > because llvm::DominatorTreeBase calls e.g. getParent()->front() > directly on the nodes and uses llvm::Inverse which forced me to >

On 04/07/2010 08:10 PM, Jochen Wilhelmy wrote: > Hi! > > while trying to use llvm::DominatorTreeBase on a custom graph that > has nothing to do with llvm::BasicBlock I ran into some difficulties, > because llvm::DominatorTreeBase calls e.g. getParent()->front() > directly on the nodes Yes this is a problem. However how is it related to your proposal? Do you want to add a

Hello, I’m trying to port a project up to 4.0 and I’m seeing the following error: In file included from /Users/jaredcarlson/Projects/llvm-4.0.0.src/include/llvm/ADT/StringRef.h:13: /Users/jaredcarlson/Projects/llvm-4.0.0.src/include/llvm/ADT/STLExtras.h:139:13: error: no type named 'type' in 'std::__1::result_of<std::__1::pointer_to_unary_function<llvm::DSNode *, llvm::DSNode

Hi there, I'm currently writing an analysis (for now) pass for LLVM that kind of need some information from the CallGraph of the program. This info would be extremely easy to get if I could build the DominatorTree information about the CallGraph. I even checked out and saw the declarations of GraphTraits templates for CallGraph and CallGraphNode, which might indicate that all algorithms that

Chris Lattner wrote: > It's more of an algorithm than a datastructure. Where else in the > codebase would it be useful to use? If only in one place, it is > probably reasonable to put it near the code that uses it. > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu

On 2009-09-06 19:57, Ioannis Nousias wrote: > Edwin, > > thank you for your effort, but I'm not sure I understand. > Are you describing a graph traversal problem? Is the data model stored > in a predecessor/successor fashion, which requires you to 'walk' the > graph in order to visit all nodes? (and what happens when you have > disjointed DFGs?). Sorry for the

Edwin, thanks, it starts making sense inline comments... Török Edwin wrote: > On 2009-09-06 19:57, Ioannis Nousias wrote: > >> Edwin, >> >> thank you for your effort, but I'm not sure I understand. >> Are you describing a graph traversal problem? Is the data model stored >> in a predecessor/successor fashion, which requires you to 'walk' the

Hi, I was reading some loop related code and I don’t quite understand an assertion in LoopBase<BlockT, LoopT>::getLoopPredecessor(). /// getLoopPredecessor - If the given loop's header has exactly one unique /// predecessor outside the loop, return it. Otherwise return null. /// This is less strict that the loop "preheader" concept, which requires /// the predecessor to have

On Aug 6, 2009, at 4:19 PM, Patrick Alexander Simmons wrote: > Chris Lattner wrote: >> On Aug 4, 2009, at 3:48 PM, Patrick Alexander Simmons wrote: >> >> >>> 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" >>>

I tried debugging it and the issue seems to be in the implementation of MachineInstrIterator.h and the way it interacts with GraphWriter.h functions. I found this by replacing the ( template <> struct GraphTraits<MCDFGraph<MachineFunction*> >) with a similar MCDFGraph based template of CFG similar to the one in MachineFunction.h (similarly replacing the DOTGraphTraits with the

Chris Lattner wrote: > On Aug 4, 2009, at 3:48 PM, Patrick Alexander Simmons wrote: > > >> 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

I am using gcc 3.2.3 on RHEL 3 to build llvm 2.2. Below are the build errors: /home/i00171/Work/llvm-work/src/llvm-2.2/include/llvm/Analysis/DominatorInternals.h:147: no type named `NodeType' in `class llvm::BasicBlock' /home/i00171/Work/llvm-work/src/llvm-2.2/include/llvm/Analysis/DominatorInternals.h:150: ` VInfo' undeclared (first use this function)

Hi, I am trying to generate the DFG of machine functions. Initially, I added a pass to generate the DFG of LLVM IR functions. This was based on the mail thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025582.html. This pass worked fine and I was able to generate DFG of LLVM IR functions. Later, I ported the DFG pass code for machine functions. I ported the InstIterator.h

On Tue, 12 Feb 2008, Sanjiv Gupta wrote: > I am using gcc 3.2.3 on RHEL 3 to build llvm 2.2. > Below are the build errors: > > /home/i00171/Work/llvm-work/src/llvm-2.2/include/llvm/Analysis/DominatorInternals.h:147: > no > type named `NodeType' in `class llvm::BasicBlock' > /home/i00171/Work/llvm-work/src/llvm-2.2/include/llvm/Analysis/DominatorInternals.h:150: >

This is release_50 branch of git, sha1: f1d5723be3f9456a6b16cdf687847ac2918846de Using gcc 7.2.0 from homebrew. $ CC=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-gcc-7 CXX=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-g++-7 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/Users/andy/local/llvm5 -DCMAKE_PREFIX_PATH=/Users/andy/local/llvm5 $ make VERBOSE=1 [ 92%] Linking CXX

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

Checking if a graph node is in a cycle or not must be a relatively common query. E.g., we used this on DS graphs to decide if DS node represented multiple objects or 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

Edwin, thank you for your effort, but I'm not sure I understand. Are you describing a graph traversal problem? Is the data model stored in a predecessor/successor fashion, which requires you to 'walk' the graph in order to visit all nodes? (and what happens when you have disjointed DFGs?). inline comments follow... Török Edwin wrote: > On 2009-09-06 17:30, Ioannis Nousias

On 2009-09-06 17:30, Ioannis Nousias wrote: > I've tried to write a DFGPrinter based on the CFGPrinter, as you > suggested, but encountered problems. > > The GraphWriter expects > GraphTraits<GraphType>::nodes_begin()/nodes_end(). The way this is > implemented in CFG.h, a function is a graph of basic blocks. A > GraphTraits<Function*> inherits from

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? (Sorry for the double post; previous patch didn't compile.) --Patrick --- include/llvm/ADT/SCCIterator.h (revision 76093) +++