search for: grapht

...des the pool allocation paper? Thanks, xiaodong Code: for( df_iterator<DSNode*> I = df_begin(pnode), E=df_end(pnode); I!=E; ++ i) { ; } Error Message: gmake Compiling MemLeakage.cpp ../../../include/Support/DepthFirstIterator.h: In member function `void df_iterator<GraphT, GT>::reverseEnterNode() [with GraphT = DSNode*, GT = GraphTraits<DSNode*>]': ../../../include/Support/DepthFirstIterator.h:49: instantiated from `df_iterator<GraphT, GT>::df_iterator(GT::NodeType*, bool) [with GraphT = DSNode*, GT = GraphTraits<DSNode*>]' ../../.....

...version of this patch some months ago and realized I've still been sitting on it. The earlier version of this patch was rejected for adding a cycle detection function to SCCIterator.h. This function is now removed. This patch makes the following changes: 1. Allow SCCIterator to work with GraphT types that are constant. 2. Allow SCCIterator to work with inverse graphs. 3. Fix an incorrect comment in GraphTraits.h (the type in the comment was given as GraphType* when it is actually const GraphType &). I think these changes should be pretty uncontroversial. Would someone with commi...

...to do a copy unless you have to). 2. Adds the inverse graph scc_begin and scc_end templates (similarly fixed to pass by constant reference rather than value). 3. Adds the cycle-detection code as "is_in_cycle" rather than "bb_reachable". 3. Fixes an incorrect comment in the GraphTraits.h header. Index: include/llvm/ADT/SCCIterator.h =================================================================== --- include/llvm/ADT/SCCIterator.h (revision 76093) +++ include/llvm/ADT/SCCIterator.h (working copy) @@ -135,8 +135,8 @@ typedef scc_iterator<GraphT, GT> _Se...

On Aug 6, 2009, at 4:19 PM, Patrick Alexander Simmons wrote: > Chris Lattner wrote: >> On Aug 4, 2009, at 3:48 PM, Patrick Alexander Simmons wrote: >> >> >>> Hi, >>> >>> I've been using scc_iterator, and I added the templates necessary to >>> make it work with inverse graphs. I also added a "bb_reachable" >>>

...> to). > 2. Adds the inverse graph scc_begin and scc_end templates (similarly > fixed to pass by constant reference rather than value). > 3. Adds the cycle-detection code as "is_in_cycle" rather than > "bb_reachable". > 3. Fixes an incorrect comment in the GraphTraits.h header. > > Index: include/llvm/ADT/SCCIterator.h > =================================================================== > --- include/llvm/ADT/SCCIterator.h (revision 76093) > +++ include/llvm/ADT/SCCIterator.h (working copy) > @@ -135,8 +135,8 @@ > typedef s...

Chris Lattner wrote: > On Aug 4, 2009, at 3:48 PM, Patrick Alexander Simmons wrote: > > >> Hi, >> >> I've been using scc_iterator, and I added the templates necessary to >> make it work with inverse graphs. I also added a "bb_reachable" >> function to tell whether an arbitrary graph node is part of cycle. >> Might this be useful to

...//llvm.org/docs/doxygen/html/Dominators_8h_source.html#l00229) If a 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...

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

Inline George > On Jan 26, 2015, at 1:05 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? Will do. :) > FWIW, my current list of CFLAA issues is: > > 1. Unknown values (results from ptrtoint, incoming

George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? FWIW, my current list of CFLAA issues is: 1. Unknown values (results from ptrtoint, incoming pointers, etc) are not treated as unknown. These should be done through graph edge (so that they can be one way, otherwise, you will unify

...oGraph would add both the `load` and `getelementptr` +// instructions to the graph appropriately. +static void addInstructionToGraph(CFLAliasAnalysis &, Instruction &, + SmallVectorImpl<Value *> &, NodeMapT &, + GraphT &); + // Builds the graph needed for constructing the StratifiedSets for the // given function static void buildGraphFrom(CFLAliasAnalysis &, Function *, @@ -816,6 +836,43 @@ static Level directionOfEdgeType(EdgeType Weight) { static void buildGraphFrom(CFLAliasAnalysis &Analysis, F...

...NId 2(%vreg4, GPR64common) moved to conservatively-allocatables. ... Popped NId 2(%vreg4, GPR64common) , all edge costs added: 2.002748e+01 inf inf inf inf inf inf inf inf inf inf ** selection: 0 llc: ../include/llvm/CodeGen/PBQP/ReductionRules.h:214: llvm::PBQP::Solution llvm::PBQP::backpropagate(GraphT&, StackT, llvm::PBQP::NodeSet&) [with GraphT = llvm::PBQP::Gra ph<llvm::PBQP::RegAlloc::RegAllocSolverImpl>; StackT = std::vector<unsigned int>; llvm::PBQP::NodeSet = std::set<unsigned int>]: Assertion `PushedAsConservativelyAllocatabl eNodes.find(NId) == PushedAsConservat...

...tively-allocatables. > > ... > > Popped NId 2(%vreg4, GPR64common) , all edge costs added: > > 2.002748e+01 inf inf inf inf inf inf inf inf inf inf ** selection: 0 > > llc: ../include/llvm/CodeGen/PBQP/ReductionRules.h:214: > llvm::PBQP::Solution llvm::PBQP::backpropagate(GraphT&, StackT, > llvm::PBQP::NodeSet&) [with GraphT = llvm::PBQP::Gra > > ph<llvm::PBQP::RegAlloc::RegAllocSolverImpl>; StackT = > std::vector<unsigned int>; llvm::PBQP::NodeSet = std::set<unsigned int>]: > Assertion `PushedAsConservativelyAllocatabl > > eN...

> A node should never be put into the conservatively allocatable list if there is a chance of it spilling. I can understand why the logic of NodeMetadata::isConservativelyAllocatable is necessary for the node to be allocatable, but I have not been able to convince myself this is sufficient, especially when the node degree > available registers. Cheers, Arnaud From:

...the (potentially shared) instance to + // i32* null. + return isa<Constant>(Val) && + !isa<GlobalValue>(Val) && + !isa<ConstantExpr>(Val); +} + static FunctionInfo buildSetsFrom(CFLAliasAnalysis &Analysis, Function *Fn) { NodeMapT Map; GraphT Graph; @@ -893,7 +906,7 @@ static FunctionInfo buildSetsFrom(CFLAliasAnalysis &Analysis, Function *Fn) { while (!Worklist.empty()) { auto Node = Worklist.pop_back_val(); auto *CurValue = findValueOrDie(Node); - if (isa<Constant>(CurValue) && !isa<GlobalV...

No, i mean the actual store instruction looks like "store i16 %conv22, i16* getelementptr inbounds ([16 x i16]* @pA, i64 0, i64 12), align 2, !tbaa !1" Not that the pointer operand comes from a GEP, but it is a constantexpr, whose opcode is GEP. It sucks that there is such a complex thing to be handled as a store operand directly , but such is life ... CFL-AA *should* treat this