search for: child_end

On Dec 20, 2007, at 3:56 PM, Mike Stump wrote: > They looked real enough to me: Fixed, thanks. -Chris > > > /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp: In > function ‘bool<unnamed>::isFPS16Immediate(llvm::ConstantFPSDNode*, > short int&)’: > /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp: > 148: warning:

They looked real enough to me: /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp: In function ‘bool<unnamed>::isFPS16Immediate(llvm::ConstantFPSDNode*, short int&)’: /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp: 148: warning: dereferencing type-punned pointer will break strict- aliasing rules

...inate as much std::tr1::function as possible I stumbled over a design flaw in llvm::df_iterator. Consider the following code: void for_all_stmts(Stmt* S, const std::tr1::function<void(Stmt*)>& fn) { if (S) { fn(S); for (Stmt::child_iterator i = S->child_begin(), e = S->child_end(); i != e; ++i) { for_all_stmts(*i, fn); } } } In a first step I want to replace this with: void for_all_stmts(Stmt* S, const std::tr1::function<void(Stmt*)>& fn) { for (llvm::df_iterator<Stmt*> i = llvm::df_begin(S), e = llvm::df_end(S); i != e; ++i) { i...

On Jun 15, 2009, at 4:33 AM, Olaf Krzikalla wrote: > While trying to eleminate as much std::tr1::function as possible I > stumbled over a design flaw in llvm::df_iterator. Ok. > However if fn replaces childrens of a just processed statement > (which happens a lot), the iteration may crash. Looking at > df_iterator reveals the reason: the first child of a particular >

...return map_iterator( G->node_begin(), DerefFun(dereference) ); } static nodes_iterator nodes_end(DSGraph *G) { return map_iterator( G->node_end(), DerefFun(dereference) ); } static ChildIteratorType child_begin(NodeType *N) { return N->begin(); } static ChildIteratorType child_end(NodeType *N) { return N->end(); } }; I”m just unsure as in 4.0, there’s a need for a NodeRef to leverage the GraphTraits template which needs to be.a pointer but I don’t think that’s all that relevant here and the above code looks consistent with what I’m used to… DSGraph::iterator by the way...

...the > graphviz data model, then iterate through them once more, checking > their predecessor/successor instructions (inputs/outputs), to register > their connectivity (edges). Right? Well the GraphTraits in DataFlow.h are really simple, LLVM's graph algorithms expect a child_begin()/child_end(), so DataFlow.h only maps child_begin/child_end to use_begin/use_end, and op_begin/op_end for the Def-Use, and Use-Def graphs respectively. That however doesn't know of any basicblock boundaries, it enumerates *all* uses of a value, so I think that writing out a full DFG is easier than writing...

...methods (and would be quite similar to GraphTraits): 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); // iterators for children of a node child_end(NodeType* node); nodes_begin(); // iterators for the nodes of a node nodes_end(); A concrete graph needs a constructor that stores a reference to the data that is to look like a graph. e.g. struct BasicBlockGraph { Function& f; BasicBlockGraph(Function& f) : f(f) {} type...

...t = nullptr; // Loop over the predecessors of the header node... BlockT *Header = getHeader(); typedef GraphTraits<Inverse<BlockT*> > InvBlockTraits; for (typename InvBlockTraits::ChildIteratorType PI = InvBlockTraits::child_begin(Header), PE = InvBlockTraits::child_end(Header); PI != PE; ++PI) { typename InvBlockTraits::NodeType *N = *PI; if (!contains(N)) { // If the block is not in the loop... if (Out && Out != N) return nullptr; // Multiple predecessors outside the loop Out = N; } } // Make sure there is onl...

...hrough them once more, checking >> their predecessor/successor instructions (inputs/outputs), to register >> their connectivity (edges). Right? >> > > > Well the GraphTraits in DataFlow.h are really simple, LLVM's graph > algorithms expect > a child_begin()/child_end(), so DataFlow.h only maps > child_begin/child_end to use_begin/use_end, and op_begin/op_end for the > Def-Use, and Use-Def graphs respectively. > That however doesn't know of any basicblock boundaries, it enumerates > *all* uses of a value, so I think that writing out a full DFG is...

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

...f XXX ChildIteratorType; > typedef XXX NodesIteratorType; > > getRoots(); // return all roots > getRoot(); // return the root if it is only one, othewise NULL > or just add these methods to GraphTraits? > > child_begin(NodeType* node); // iterators for children of a node > child_end(NodeType* node); > > nodes_begin(); // iterators for the nodes of a node > nodes_end(); > > > A concrete graph needs a constructor that stores a reference to the data > that is to look like a graph. > e.g. > struct BasicBlockGraph > { > Function& f; > &gt...

...basic block A splits into A->B, when I call Split(), which is NewBB? A or B? The semantics shows that NewBB is the newly split basic block B. But the assertion at line 229 doesn't seem right. 00229 assert(std::distance(GraphT::child_begin(NewBB), 00230 GraphT::child_end(NewBB)) == 1 && 00231 "NewBB should have a single successor!"); If A has 2 successors C, D, after it split to A->NewBB, NewBB should have 2 successors. Hope anyone could explain this to me. Thanks, Vu On Sat, Jan 22, 2011 at 10:28 PM, Vu Le <vmle at ucdavis.edu&...

...nt 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); // iterators for children of a node > child_end(NodeType* node); > > nodes_begin(); // iterators for the nodes of a node > nodes_end(); > > > A concrete graph needs a constructor that stores a reference to the data > that is to look like a graph. > e.g. > struct BasicBlockGraph > { > Function& f; >...

There might be a misuse of DominatorTree::splitBasicBlock in CodeExtractor.cpp, line 145. Header is splited into two (OldPred->NewBB). Line 145 updates the dominator tree by calling DT->splitBasicBlock(NewBB). I think it should be DT->splitBasicBlock(OldPred). When I tried to extract a code region whose header has 2 successors, my pass crashed. It was because header (or OldPred) is the

...clude/llvm/Analysis/Dominators.h:666:35: error: no viable conversion from 'typename TraitsTy::nodes_iterator' (aka 'mapped_iterator<CallGraph::iterator, DerefFun>') to 'NodeType *' (aka 'llvm::CallGraphNode *') if (TraitsTy::child_begin(I) == TraitsTy::child_end(I)) ^ /Developer/llvm/lib/Transforms/ThreadBufferOptimizer/ThreadBufferOptimizer.h:59:10: note: in instantiation of function template specialization 'llvm::DominatorTreeBase<llvm::CallGraphNode>::recalculate<llvm::CallGraph>' requested here...

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