similar to: [LLVMdev] CFG Customization

Hi John, thank you for your answer. Sorry if I was not clear ^^' I try to build a RCG (Resource Control Graph) which is a CFG with a weight. In my case, this weight corresponds to the number of heap allocations. Then I want to add this weight to each node (then basic block) of this graph. I think that a CFG is a GraphTraits<BasicBlock*> then I suppose that this RCG will be a

Hi, I want to instrument every control-flow edge in a CFG. What is the best way to do this ? I was thinking of getting a reference to the CFG using GraphTraits<Function *>. Is there a simple way to get the CFG handle? Thanks.

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

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

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.

Hi, Well, yes i did try your suggestion but i keep on running into a compilation problem. The error is: llvm[0]: Compiling Hello.cpp for Release build (PIC) /home/saraswat/llvm/llvm-2.1/include/llvm/ADT/GraphTraits.h: In instantiation of `llvm::GraphTraits<llvm::ilist_iterator<llvm::BasicBlock> >': Hello.cpp:59: instantiated from here

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 implement my GraphTraits also for Inverse. This could be solved using a compile time abstraction of Graph instread of

Hi all, Is there a way to walk through ALL the predecessors of a basic block in a CFG. I tried to iterate over the preds using this method for (pred_iterator PI = pred_begin(BB), E = pred_end(BB); PI != E; ++I) { BasicBlock *PredBB = *PI; } but this only gives the immediate predecessors for a basic block. For example, in this sample control flow graph. entry -> bb1 -> bb2 -> bb4

On Wed, Jan 18, 2017 at 8:05 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/18/2017 2:56 AM, Thomas RUBIANO wrote: > > Ty Eli for your answer. > > On Tue, Jan 17, 2017 at 8:11 PM, Friedman, Eli <efriedma at codeaurora.org> > wrote: > >> On 1/17/2017 7:12 AM, Thomas RUBIANO via llvm-dev wrote: >> >>> Hi all! >>>

Hi Pabhat, Have you checked out DepthFirstIterator? (include/llvm/ADT/ DepthFirstIterator.h). It provides an iterator abstraction to perform a forward/reverse DFS traversal of a graph. Many of the LLVM datatypes that represent graphs have a template specialization of the GraphTraits<> class which allows separate algorithms to treat them as graphs, walk them, etc. (Both BasicBlock

Hi Nick, On Mar 28, 2008, at 02:15, Nick Lewycky wrote: > Before I start investing time implementing these changes, does > anyone foresee any problems that I missed? Stepping back from the nuts and bolts for a moment, could you precisely define what constitutes a predecessor in this model? What blocks would a phi node in %catch require for a case like this? define i8 @f(i1 %b) {

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

Ty Eli for your answer. On Tue, Jan 17, 2017 at 8:11 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/17/2017 7:12 AM, Thomas RUBIANO via llvm-dev wrote: > >> Hi all! >> >> I'm new here, and would like to implement my own Loop Invariant Detection >> adding some more information on Quasi-Invariants. >> >> First, is there anything

I have a new plan for handling 'unwinds to' in the control flow graph and dominance. Just as a quick recap the problem I encountered is how to deal instructions in a block being used as operands in the unwind dest. Such as this: bb1: unwinds to %cleanup call void @foo() ; might throw, might not %x = add i32 %y, %z call void @foo() ; might throw, might not ret void cleanup:

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

Gordon Henriksen wrote: > What blocks would a phi node in %catch require for a case like this? > > define i8 @f(i1 %b) { > > entry: > > b label %try > > try: unwinds to %catch > > b i1 %b, label %then, label %else > > then: unwinds to %catch > > ret void > > else: unwinds to %catch > > ret

Thank you again Eli, I would like to know if it's not better to use DependenceAnalysis to know which instruction depends on others… I'm running this pass on a simple example: … while.body: ; preds = %while.cond %1 = load i32, i32* %y, align 4 ← I1 %2 = load i32, i32* %y, align 4 %mul = mul nsw i32 %1, %2 ← I2 store i32 %mul, i32* %z, align 4

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 >