similar to: [LLVMdev] Graphviz and LLVM-TV

Hi Ioannis, On Thu, 2009-08-13 at 19:31 +0100, Ioannis Nousias wrote: > Thanks Tobi for the tip. > > 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.

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

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

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

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 GraphTraits<BasicBlock*>, and implements those nodes_begin()/nodes_end()

On Thu, 2009-08-13 at 17:17 +0100, Ioannis Nousias wrote: > Chris Lattner wrote: > > On Aug 13, 2009, at 8:56 AM, Ioannis Nousias wrote: > > > 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

On Aug 13, 2009, at 8:56 AM, Ioannis Nousias wrote: > 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

Chris Lattner wrote: On Aug 13, 2009, at 8:56 AM, Ioannis Nousias wrote: > 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 >

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

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

On Tue, Aug 18, 2009 at 10:45 AM, Misha Brukman <brukman at gmail.com> wrote: > On Thu, Aug 13, 2009 at 12:17 PM, Ioannis Nousias < > ioannis.nousias at googlemail.com> wrote: > >> >> Also, LLVM-TV seems outdated. I've tried to compile it with 2.5 LLVM >> and >> >> got various errors due to API changes. Tried to correct them, but got >>

On Thu, Aug 13, 2009 at 12:17 PM, Ioannis Nousias < ioannis.nousias at googlemail.com> wrote: > >> Also, LLVM-TV seems outdated. I've tried to compile it with 2.5 LLVM and > >> got various errors due to API changes. Tried to correct them, but got > >> overwhelmed. Has the project been abandoned? > > > > Yes, it is really really old and abandoned.

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 introduced these new flags: -dot-dom : Print dominance tree of function to 'dot' file -dot-dom-only : Print dominance tree of function to 'dot' file (with no function

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

Tobias Grosser wrote: > 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 Great! I'm a huge fan of graphviz integration in the compiler. > And here is the

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:

Just a quick question, Any ideas why Fedora 7 is still on Compiz 0.3.6? Currently the main repository has 0.3.6 and the development one has 0.4. Shouldn't it be 0.4 for the main and 0.5 for the development? Does 0.4 break anything? -Ioannis

Hi, The -dot-cfg option of opt will write a diagram of an analyzed function's CFG to DOT format. If you then open the DOT file, you will see that the BasicBlocks are uniquely identified with hexadecimal addresses. For example, an edge from one block to another may look like: Node0x10026b0:s0 -> Node0x1004c20; I've been trying to figure out where these hexadecimal addresses

Hello, I'm using Fedora 7 and I thought I should try nouveau. I couldn't get direct rendering to work. I found out that the Mesa package that ships with Fedora 7 doesn't include a DRI interface for the nouveau module. So I fetched the latest Mesa source from git, compiled with 'mke DRI_DIRS=nouveau linux-dri-x86' and copied the produced ./lib/nouveau_dri.so in the