search for: getroots

On Oct 30, 2010, at 4:38 AM, Duncan Sands wrote: >> Is there any facility in LLVM to identify recursion in a call graph? ... > use the facilities in SCCIterator.h, or declare your pass to be a > CallGraphSCCPass in which case it will work one strongly connected > component at a time. Converting my ModulePass to a CallGraphSCCPass doesn't seem feasible, so I'll use

...its also for Inverse. This 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): 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 r...

Hi you basically need to find a cycles in the call graph. Do do this just search google for a graph algorithm, then make it for your problem. See http://en.wikipedia.org/wiki/Cycle_detection. Jeff Kunkel On Tue, Nov 2, 2010 at 4:27 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Trevor, > > > Converting my ModulePass to a CallGraphSCCPass doesn't seem feasible, so >

Hi Trevor, > Converting my ModulePass to a CallGraphSCCPass doesn't seem feasible, so I'll > use llvm::scc_iterator. Here's what I have so far: > > bool MyModulePass::isRecursive() { > CallGraphNode* rootNode = getAnalysis<CallGraph>().getRoot(); > for (scc_iterator<CallGraphNode*> SCCI = scc_begin(rootNode), E = > scc_end(rootNode); SCCI != E; ++SCCI)

Hi, I'm a newbie to R package submission. I've written a program using basic functions inside R to manipulate phylogeny tree data. I've relied on the APE package. After almost year of working on it, it's time for me to submit the package and I have very little time to rewrite it as S3/4 style unless it is required. It's just very basic at the moment with 30+ functions 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); // iterators for children of a node > child_end(NodeType* node); > > nodes_begin(); // iterators for the nodes of a node > nodes_end(); > > > A conc...

I've got a question about how SelectionDAGBuilder treats loads. The LLVM Language Reference Manual explicitly states that the order of volatile operations may be changed relative to non-volatile operations. However, when the SelectionDAGBuilder in LLVM 3.1 encounters a volatile load, it flushes all pending loads and then chains the volatile load onto them meaning that the volatile load must

...ng 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): > > typedef XXX NodeType; > typedef 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...

Hello, I did a little experiment modifying LLVM to be able to use alias-analysis information in scheduling so that independent memory operations may be reordered. Attached is a patch which implements this. I copied some routines from DAGCombiner.cpp for using SDOperands with alias queries; it should probably be factored out somewhere so the code can be shared. I reorganized

Also, could you write this in a separate pass, and obtain the results from getAnalysis()? I think others would find it useful to discover if a Function may be called recursively. -Jeff Kunkel On Tue, Nov 2, 2010 at 2:38 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: > Hi you basically need to find a cycles in the call graph. Do do this just > search google for a graph algorithm, then

Steve, I had created a patch last year that does something similar to what you describe for regular loads and stores using aliasing information. I think that the last message in the thread was: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120402/140299.html This approach has worked for me, but it is not the preferred solution going forward. The preferred solution is to keep the

Hi Chris, Your were totally right with your suggestion. I have implemented the code that : a) does not merge multiple TokenFactor nodes in the DAGCombiner::visitTokenFactor(), if the resulting TF node would contain more than 64 operands. b) produces a bunch of TokenFactor nodes with at most 64 operands, instead of one huge TokenFactor in the SelectionDAGLowering::getRoot(). If we have n

I need to generate line number debug information for PIC16 target. PIC16 does not support dwarf format. It supports coff format. So I need to custom handle the STOPPOINT nodes. Without -fast option the STOPPOINT nodes are not created in dag because of the below check in SelectionDAGBuild.cpp if (Fast) DAG.setRoot(DAG.getDbgStopPoint(getRoot(), If I give -fast option then the Fast

Hi Chris, This is a good idea and I started thinking in that direction already. But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to. For example now: > PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the > TokenFactor node by SelectionDAGLowering::getRoot called from the >

Hi, I'm not sure. But in your lowered DAG the chain nodes are the first operands for you custom nodes, however for the other nodes the chain is the last operand. I seem to remember that during targetlowering the chain is the first operand and then it seems to switch over after ISelDAG, this confused me and may have something to do with the issue that you are seeing. I really don't

...d 100644 --- a/include/llvm/Analysis/DominanceFrontier.h +++ b/include/llvm/Analysis/DominanceFrontier.h @@ -52,7 +52,7 @@ protected: static constexpr bool IsPostDominators = IsPostDom; public: - DominanceFrontierBase() = default; + DominanceFrontierBase() { } /// getRoots - Return the root blocks of the current CFG. This may include /// multiple blocks if we are computing post dominators. For forward seems to fix the problem and I think is related to this GCC defect https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728 I'm unsure about the level of in...

Hi, Is there any facility in LLVM to identify recursion in a call graph? I realize this is undecidable in the general case due to function pointers, but at least the static cases could be identified. I don't even care about whole-program recursion, just looking at a single module would suffice. But I don't see anything like this already in LLVM, so do I simply write some code to

Hi Trevor, > Is there any facility in LLVM to identify recursion in a call graph? I > realize this is undecidable in the general case due to function > pointers, but at least the static cases could be identified. I don't > even care about whole-program recursion, just looking at a single > module would suffice. But I don't see anything like this already in > LLVM, so do

Hi everyone, In order to have exceptions for non-call instructions (such as sdiv, load or stores), I'm modifying codegen so that it generates a BeginLabel and an EndLabel between the "may throwing" instruction. This is what the codegen of an InvokeInst does. However, when generating native code, only BeginLabel is generated, and it is generated after the instruction. I'm not

I looked into those patches but I don't think they will help in my situation because my problems occur during instruction selection rather than scheduling. A simple and concrete example is a pattern like: [(set GR:$dst (add GR:$src (nvload addr:$mem)))] where nvload matches a load provided that isVolatile() is false. If the selection DAG looks like: | | LD1 LD2 ^