search for: getroot

...it will work one strongly connected > component at a time. 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) { const std::vector<CallGraphNode*> &nextSCC = *SCCI; if (nextSCC.size() == 1 && SCCI.hasLoop()) { return true; } } return false; } This correctly identi...

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

...revor, > > > 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) { > > const std::vector<CallGraphNode*> &nextSCC = *SCCI; > > if (nextSCC.size() == 1 && SCCI.hasLoop()) { > > return true; > &...

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) { > const std::vector<CallGraphNode*> &nextSCC = *SCCI; > if (nextSCC.size() == 1 && SCCI.hasLoop()) { > return true; > } > } > return false...

...e unless it is required. It's just very basic at the moment with 30+ functions and there's a driver class. There's a lot of jargon in package submission and so it's difficult to understand the Google results. I would appreciate any help. 1. My functions are very basic. For example, getRoot gets the root of the current tree (APE phylo object) and getAncestor gets the ancestor to the current node: getRoot <- function(cur_Tree){ return(length(cur_Tree$tip.label)+1) } getAncestor <- function(cur_Node, cur_Tree){ ... return(ancestor) } Is this okay or do I have to do anything...

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

...volatile load must be scheduled after those loads. While this behaviour isn't wrong, it seems to reduce the scope for efficient instruction selection. Is there any reason not to modify the behaviour of SelectionDAGBuilder::visitLoad() so that volatile loads don't cause SelectionDAGBuilder::getRoot() to be called. Instead, they can be chained together with the head of the chain being stored in PendingLoads. Then when something else calls SelectionDAGBuilder::getRoot(), the chain of volatile loads is TokenFactored together with the non-volatile loads. I've tried this out and it seems to do...

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

...perand getStoreRoot(SDOperand StoreAddr, + int64_t StoreSize, + const Value *StoreAddrValue, + int StoreOffset) { + // The special behavior may be disabled by an option. + if (!SchedulerMemoryDisambiguation) + return getRoot(); + + std::vector<SDOperand> DependentMemOps, IndependentMemOps; + + for (std::vector<SDOperand>::iterator I = PendingLoads.begin(), + E = PendingLoads.end(); I != E; ++I) { + SDOperand PendingMemOp = *I; + + SDOperand OpPtr; + int64_t OpSize; + const...

...; 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) { >> > const std::vector<CallGraphNode*> &nextSCC = *SCCI; >> > if (nextSCC.size() == 1 && SCCI.hasLoop()) { >> >...

...d after those loads. While this behaviour isn't > wrong, it seems to reduce the scope for efficient instruction > selection. > > Is there any reason not to modify the behaviour of > SelectionDAGBuilder::visitLoad() so that volatile loads don't cause > SelectionDAGBuilder::getRoot() to be called. Instead, they can be > chained together with the head of the chain being stored in > PendingLoads. Then when something else calls > SelectionDAGBuilder::getRoot(), the chain of volatile loads is > TokenFactored together with the non-volatile loads. I've tried this &g...

...ented 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 pending loads, they can be combined into TFs in two ways: 1) The first 64 loads are put into a new node TF1. Then TF1 and the next 64 loads are put into a new node TF2 and so on. That is, each generated TF contains a previous TF as its first operand and a bunch of pending loa...

...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 flag is true, but the dag doesn't contain STOPPOINT nodes. If I have simple loads and stores in source code, the dag doesn't contain them too. Why are these nodes not being created? Thanks Vasudev

...ed 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 > SelectionDAGLowering::visitStore So, if I now detect in the getRoot that there are more than let's say 64 nodes in the PendingLoads queue, what should I do? - Can I take only 64 of them and forget about the rest by ignoring them? - Or should I produces a series of TFs...

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

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

...owever, when generating native code, only BeginLabel is generated, and it is generated after the instruction. I'm not familiar with DAGs in the codegen library, so here are my 2-cents thoughts why: 1) BeginLabel and EndLabel are generated with: DAG.setRoot(DAG.getNode(ISD::LABEL, MVT::Other, getRoot(), DAG.getConstant({Begin|End}Label, MVT::i32))); This seems to work with InvokeInst instructions, because the root of the DAG is modified by the instruction. With instructions such as sdiv, the root is not modified: the instruction only lowers itself to: DAG.getNode(Op...

...le this behaviour isn't >> wrong, it seems to reduce the scope for efficient instruction >> selection. >> >> Is there any reason not to modify the behaviour of >> SelectionDAGBuilder::visitLoad() so that volatile loads don't cause >> SelectionDAGBuilder::getRoot() to be called. Instead, they can be >> chained together with the head of the chain being stored in >> PendingLoads. Then when something else calls >> SelectionDAGBuilder::getRoot(), the chain of volatile loads is >> TokenFactored together with the non-volatile loads. I'...