search for: dotgraphtraits

...F.viewCFG(); + F.viewCFGOnly(); return false; } Put that back. viewCFG shows the CFG with full instructions inside it while viewCFGOnly shows just the block without the instruction listing inside. This pass is intended to show the details. + template<> + struct DOTGraphTraits<DomTreeNode*> : public DefaultDOTGraphTraits { + static std::string getNodeLabel(DomTreeNode *Node, + DomTreeNode *Graph, + bool ShortNames) { Tabs are forbidden in LLVM. Also, neither "namespace llvm {" nor "template<>" increase indent level...

Hi all, I have two questions related to .dot graph output. Basically, I have a graph representing a program dependence graph like structure with (a) multiple edges between the same pair of nodes (b) each edge having a special (different) text/label I implemented a template-specialized version of DotGraphTraits for the my graph structure which given a node, uses a map_iterator (similar to the one used in CallGraph) to get the destination node of an outgoing edge. This works fine except that I have no clue how to support (a) and (b) since once the destination node is returned I lose access to the edge and...

...stions related to .dot graph output. Basically, I have a > graph representing a program dependence graph like structure with > (a) multiple edges between the same pair of nodes > (b) each edge having a special (different) text/label > > I implemented a template-specialized version of DotGraphTraits for the > my graph structure which given a node, uses a map_iterator (similar to > the one used in CallGraph) to get the destination node of an outgoing > edge. This works fine except that I have no clue how to support (a) > and (b) since once the destination node is returned I lose acc...

...;>> have a >>> graph representing a program dependence graph like structure with >>> (a) multiple edges between the same pair of nodes >>> (b) each edge having a special (different) text/label >>> >>> I implemented a template-specialized version of DotGraphTraits for >>> the >>> my graph structure which given a node, uses a map_iterator >>> (similar to >>> the one used in CallGraph) to get the destination node of an >>> outgoing >>> edge. This works fine except that I have no clue how to support (a...

...ot graph output. Basically, I have a >> graph representing a program dependence graph like structure with >> (a) multiple edges between the same pair of nodes >> (b) each edge having a special (different) text/label >> >> I implemented a template-specialized version of DotGraphTraits for the >> my graph structure which given a node, uses a map_iterator (similar to >> the one used in CallGraph) to get the destination node of an outgoing >> edge. This works fine except that I have no clue how to support (a) >> and (b) since once the destination node is ret...

Hi all, I need to look at the CFG of a loop during debugging. However the containing function is very large, so it is rather difficult to use the CFG of the complete function. I tried using the ViewGraph method, but the compiler kept complaining about undefined symbols related to GraphTraits or DOTGraphTraits. Is there any example that I could look at to find out, what exactly I need to call something like ViewGraph(loop, "CFG") ? Martin

...-dom-only : View dominance tree of function (with no function bodies) -view-postdom : View postdominance tree of function -view-postdom-only : View postdominance tree of function (with no function bodies) The patch contains these changes: 1. Move DOTGraphTraits<const Function*> to CFGPrinter.h to reuse it later. 2. Add nodes_iterator to GraphTraits<DomTreeNode *>, GraphTraits<DominatorTree*>, GraphTraits<PostDominatorTree*> to enable the GraphWriter on these data structures. 3. The file DomPrinter.cpp containing the actual passes...

...t; > however I also need the Data-Flow-Graph of each basic block/functions. > As I said, I need a view of how the instructions 'link' to each other > (via registers or memory aliasing or whatnot) I believe that there is not yet a DOT printer for this kind of information. grep DOTGraphTraits -R * should give you all data types, for which dot printing is implemented, and the data flow does not seem to exist. However there is already a graph representation of the data flow information in "include/llvm/Support/DataFlow.h": ------------------------------------------------------...

...ef mc_inst_iterator nodes_iterator; static nodes_iterator nodes_begin(MCDFGraph<MachineFunction *> F) { return mc_inst_begin(*F); } static nodes_iterator nodes_end(MCDFGraph<MachineFunction *> F) { return mc_inst_end(*F); } }; template<> struct DOTGraphTraits<MCDFGraph<MachineFunction*> > : public DefaultDOTGraphTraits { DOTGraphTraits (bool isSimple=false) : DefaultDOTGraphTraits(isSimple) {} static std::string getGraphName(MCDFGraph<MachineFunction *> F) { return "DFG for the function"; } static std...

...chineInstrIterator.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 one for CFG) and it works and pops up the GraphViz window with the CFG for the machine function. I am attaching the MachineInstrIterator.h file. Also, I wrote a pass using the mc_inst_iterator (defined in the MachineInstrIterator.h - the direct iterator over MachineInstr in a MachineFunc...

On Wed, 2009-07-15 at 00:20 +0200, Tobias Grosser wrote: > Hi, > > I started to work with llvm and liked the CFG dotty printer a lot. > However there was none for the dominance trees. > > I implemented dotty printing for dominance trees And here is the patch. Tobi -------------- next part -------------- A non-text attachment was scrubbed... Name:

...-> Node0x1004c20; I've been trying to figure out where these hexadecimal addresses come from. I've been up and down the code but remain at a loss. I can see where GraphWriter.h is actually writing the strings to the DOT file, and I can see that some of the DOT data is coming from DOTGraphTraits in CFGPrinter.h. But the hexadecimal addresses are a mystery. I thought perhaps a BasicBlock method, such as getName, might be producing the addresses, but no. Can anyone shed some light on this for me? Thanks, Trevor

...Indeed, to view the call graph one should tell opt to dump it to a file and then open it with a DOT viewer. So I started adding support for viewing the call graph from opt. Basically, there are 2 alternatives: 1) If you are trying to print/view a graph that is a Function analysis, then exploit DOTGraphTraits{Viewer,Printer} * lib/Analysis/DomPrinter.cpp * lib/Analysis/RegionPrinter.cpp 2) Otherwise, use low-level interface {View,Write}Graph * lib/Analysis/CFGPrinter.cpp - View the graph, defines passes for viewing/printing * lib/CodeGen/SelectionDAG/SelectionDAGPrinter.cpp * lib/C...

Hi I'm trying to get a graphviz output (DOT) of a code I'm compiling. I want to see the DFG/CFG of the LLVM assembly, how the operations are chained together. The documentation mentions something about calling certain methods from within gdb, but isn't there some option when invoking the compiler (I've seen some -print-cfg and -dot-cfg options mentioned in some source files,

...terator nodes_iterator; static nodes_iterator nodes_begin(DFG<Function *> F) { return inst_begin(*F); } static nodes_iterator nodes_end(DFG<Function *> F) { return inst_end(*F); } }; ... ViewGraph(DFG<Function*>(F), "test"); Then you could implement a DOTGraphTraits for DFG<Function*>. > > inline comments follow... > > Török Edwin wrote: >> 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. >>&gt...

..._begin(DFG<Function *> F) { > return inst_begin(*F); > } > static nodes_iterator nodes_end(DFG<Function *> F) { > return inst_end(*F); > } > }; > > ... > ViewGraph(DFG<Function*>(F), "test"); > > Then you could implement a DOTGraphTraits for DFG<Function*>. > > ok I'll give it a try. >> inline comments follow... >> >> Török Edwin wrote: >> >>> On 2009-09-06 17:30, Ioannis Nousias wrote: >>> >>> >>>> I've tried to write a DFGPrinter...

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

...is matched with the names of the labels of nodes when displaying a graph, so that matching nodes are displayed in a colored bold style. I find this extremely usful on selectionDAGs to spot specific nodes in larger graphs. You may complain that the implementation should be interacting more with the DOTGraphTraits class, but OTOH this might be an interesting feature for any type of graph, and as such it is certainly the lightest implementation. Anyway, if this is considered an interesting feature for the mainline but unacceptable this way please let me know, I might eventually change it according to your sug...

...could be solved using a compile time abstraction of Graph > instread of GraphTraits. > > the abstraction has to provide some typedefs and methods > (and would be quite similar to GraphTraits): I definitely support adding multiple tree roots to the graph interface. This will allow the DOTGraphTraits based printers to not only print trees. > typedef XXX NodeType; > typedef XXX ChildIteratorType; > typedef XXX NodesIteratorType; > > getRoots(); // return all roots > getRoot(); // return the root if it is only one, othewise NULL > > child_begin(NodeType* node); // iterato...

...of each basic block/functions. >> As I said, I need a view of how the instructions 'link' to each other >> (via registers or memory aliasing or whatnot) >> > > > I believe that there is not yet a DOT printer for this kind of > information. > > grep DOTGraphTraits -R * > > should give you all data types, for which dot printing is implemented, > and the data flow does not seem to exist. However there is already a > graph representation of the data flow information in > "include/llvm/Support/DataFlow.h": > > ---------------------...