search for: getrootnode

...am trying to traverse a dominator tree and have encountered a weird > runtime exception: > > Here's my simple code: > > virtual bool runOnFunction(Function &F) { > DominatorTree& DT = getAnalysis<DominatorTree>(); > > * DomTreeNode* rootNode = DT.getRootNode();* > return false. > } > > Here's the documentation page: > http://llvm.org/docs/doxygen/html/classllvm_1_1DominatorTree.html > > And here's my runtime exception: > dyld: lazy symbol binding failed: Symbol not found: > __ZN4llvm17DominatorTreeBaseINS_10Basic...

Hi all, I am trying to traverse a dominator tree and have encountered a weird runtime exception: Here's my simple code: virtual bool runOnFunction(Function &F) { DominatorTree& DT = getAnalysis<DominatorTree>(); * DomTreeNode* rootNode = DT.getRootNode();* return false. } Here's the documentation page: http://llvm.org/docs/doxygen/html/classllvm_1_1DominatorTree.html And here's my runtime exception: dyld: lazy symbol binding failed: Symbol not found: __ZN4llvm17DominatorTreeBaseINS_10BasicBlockEE11getRootNodeEv Referenced from:...

...countered a >> weird runtime exception: >> >> Here's my simple code: >> >> virtual bool runOnFunction(Function &F) { >> DominatorTree& DT = getAnalysis<DominatorTree>(); >> >> * DomTreeNode* rootNode = DT.getRootNode();* >> return false. >> } >> >> Here's the documentation page: >> http://llvm.org/docs/doxygen/html/classllvm_1_1DominatorTree.html >> >> And here's my runtime exception: >> dyld: lazy symbol binding failed: Symbol...

...ng to traverse a dominator tree and have encountered a weird > runtime exception: > > Here's my simple code: > > virtual bool runOnFunction(Function &F) { > DominatorTree& DT = getAnalysis<DominatorTree>(); > > * DomTreeNode* rootNode = DT.getRootNode();* > return false. > } > > Here's the documentation page: > http://llvm.org/docs/doxygen/html/classllvm_1_1DominatorTree.html > > And here's my runtime exception: > dyld: lazy symbol binding failed: Symbol not found: > __ZN4llvm17DominatorTreeBaseINS_10B...

...and have encountered a weird >> runtime exception: >> >> Here's my simple code: >> >> virtual bool runOnFunction(Function &F) { >> DominatorTree& DT = getAnalysis<DominatorTree>(); >> >> * DomTreeNode* rootNode = DT.getRootNode();* >> return false. >> } >> >> Here's the documentation page: >> http://llvm.org/docs/doxygen/html/classllvm_1_1DominatorTree.html >> >> And here's my runtime exception: >> dyld: lazy symbol binding failed: Symbol not found: >>...

...urceforge.jnlp.runtime.Boot.run(Boot.java:62) at java.security.AccessController.doPrivileged(Native Method) at net.sourceforge.jnlp.runtime.Boot.main(Boot.java:198) Caused by: net.sourceforge.jnlp.ParseException: Invalid XML document syntax. at net.sourceforge.jnlp.XMLParser.getRootNode(XmlParser.java:118) at net.sourceforge.jnlp.MalformedXMLParser.getRootNode(MalformedXMLParser.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.Deleg...

Hi George, > When I compile llvm in release mode, the problem goes away! I don't understand? probably the function defined in the header is inlined into every function that calls it when optimization is turned on, but not when optimization is turned off. Ciao, Duncan.

...MBBI = po_begin(Fn.getBlockNumbered(0)), + MBBE = po_end(Fn.getBlockNumbered(0)); MBBI != MBBE; ++MBBI) { + MachineBasicBlock* MBB = *MBBI; ... + // Calculate Avail{In,Out} via top-down walk of Machine dominator tree. + for (df_iterator<MachineDomTreeNode*> DI = df_begin(DT.getRootNode ()), + E = df_end(DT.getRootNode()); DI != E; ++DI) { Later in +/// placeSpillsAndRestores - decide which MBBs need spills, restores +/// of CSRs. +/// +void PEI::placeSpillsAndRestores(MachineFunction &Fn) { ... + // Calculate CSRRestore using post-order traversal of Machine-CFG....

Hello, Bug is already fixed by Chris (see: http://llvm.org/bugs/show_bug.cgi?id=4915) . I added getRootNode() == NULL condition to my patch. It's not a great solution, but it is enough for now I think. New patch attached. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: dse_ssu-2.patch Type: application/octet-stream Size: 17762 bytes Desc: not available UR...

...I am using the Postdom pass and I would like to get the root of the tree. However, everytime I try to get the root, I get a segfault. I don't know why the environment can't find DominatorTreeBase. Below is the code that generates the Segfault. In my .h file I include Dominators.h PDT.getRootNode(); //PDT is a reference to a PostDominatorTree dyld: lazy symbol binding failed: Symbol not found: __ZN4llvm17DominatorTreeBaseINS_10BasicBlockEE11getRootNodeEv Referenced from: /Users/georgebaah/Software/llvm3.1/build/Debug+Asserts/bin/../lib/LLVMNshira.dylib Expected in: flat namespace dyl...

Here is an updated patch for shrink wrapping with: - spills/restores done with stack slot stores/loads - stack adjustment removed - refactoring (but still in need of more) - spill/restore insertion code unified with spill/restore placement code Documentation available here<http://wiki.github.com/jdmdj/llvm-work/shrink-wrapping-work> illustrates shrink wrapping with loops and discusses a

Hi, It looks like PDT.getRootNode() returns NULL for: define fastcc void @c974001__lengthy_calculation. 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { entry: br label %bb bb: br label %bb } Isn't it a bug in PostDominatorTree? Please note that this crashes: opt -postdomtree -debug dom_crash.bc I think...

Jakub Staszak wrote: > Hi, > > It looks like PDT.getRootNode() returns NULL for: > > define fastcc void @c974001__lengthy_calculation. > 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { > entry: > br label %bb > > bb: > br label %bb > } > > > Isn't it a bug in PostDominatorTree? > > Please...

On Mon, Mar 2, 2009 at 10:35 AM, Evan Cheng <echeng at apple.com> wrote: > > On Mar 1, 2009, at 2:57 PM, John Mosby wrote: > > Obviously, all of this applies only when spills are done with push/pop, > which is the case on x86. I used this issue to start looking at generalizing > how spills and restores are handled, before looking too closely at other > targets, and

...; > + MBBE = po_end(Fn.getBlockNumbered(0)); MBBI != MBBE; ++MBBI) { > > > + MachineBasicBlock* MBB = *MBBI; > ... > + // Calculate Avail{In,Out} via top-down walk of Machine dominator tree. > > > + for (df_iterator<MachineDomTreeNode*> DI = df_begin(DT.getRootNode()), > > > + E = df_end(DT.getRootNode()); DI != E; ++DI) { > > > Later in > +/// placeSpillsAndRestores - decide which MBBs need spills, restores > > > +/// of CSRs. > > > +/// > > > +void PEI::placeSpillsAndRestores(MachineFunction &Fn) {...

...../../lib/libLLVMCore.a(Dominators.cpp.o) duplicate symbol llvm::DominatorTreeBase<llvm::BasicBlock, true>::wipe() in: ../../lib/libLLVMAnalysis.a(PostDominators.cpp.o) ../../lib/libLLVMCore.a(Dominators.cpp.o) duplicate symbol llvm::DominatorTreeBase<llvm::BasicBlock, true>::getRootNode() in: ../../lib/libLLVMAnalysis.a(PostDominators.cpp.o) ../../lib/libLLVMCore.a(Dominators.cpp.o) duplicate symbol llvm::DominatorTreeBase<llvm::BasicBlock, true>::getRootNode() const in: ../../lib/libLLVMAnalysis.a(PostDominators.cpp.o) ../../lib/libLLVMCore.a(Dominators.c...

...n.getBlockNumbered(0)); MBBI != MBBE; ++MBBI) { >> >> >> +    MachineBasicBlock* MBB = *MBBI; >> ... >> +  // Calculate Avail{In,Out} via top-down walk of Machine dominator tree. >> >> >> +  for (df_iterator<MachineDomTreeNode*> DI = df_begin(DT.getRootNode()), >> >> >> +         E = df_end(DT.getRootNode()); DI != E; ++DI) { >> >> Later in >> +/// placeSpillsAndRestores - decide which MBBs need spills, restores >> >> >> +/// of CSRs. >> >> >> +/// >> >> >> +void...

On Aug 24, 2009, at 4:58 PM, Jonathan Ragan-Kelley wrote: > Many published analyses which build on post-dominance assume a > canonical single-dominator-tree form induced by unifying all exits > (and often adding a virtual edge from START to END). In contrast, it > seems that the current LLVM post-dominator analysis only operates in a > mode in which it generates a forest of

...lt;< "] " << N; ^ /Developer/llvm/include/llvm/Analysis/Dominators.h:558:7: note: in instantiation of function template specialization 'llvm::PrintDomTree<llvm::CallGraphNode>' requested here PrintDomTree<NodeT>(getRootNode(), o, 1); ^ /Developer/llvm/lib/Transforms/ThreadBufferOptimizer/ThreadBufferOptimizer.h:61:10: note: in instantiation of member function 'llvm::DominatorTreeBase<llvm::CallGraphNode>::print' requested here DTB->print(errs()); ^ 4 errors generated. Cheers,...

Many published analyses which build on post-dominance assume a canonical single-dominator-tree form induced by unifying all exits (and often adding a virtual edge from START to END). In contrast, it seems that the current LLVM post-dominator analysis only operates in a mode in which it generates a forest of post-dominator trees, with one rooted at each exit node. The problem this can cause is