search for: getentrynod

...==== --- include/llvm/ADT/SCCIterator.h (revision 76093) +++ include/llvm/ADT/SCCIterator.h (working copy) @@ -135,8 +135,8 @@ typedef scc_iterator<GraphT, GT> _Self; // Provide static "constructors"... - static inline _Self begin(GraphT& G) { return _Self(GT::getEntryNode(G)); } - static inline _Self end (GraphT& G) { return _Self(); } + static inline _Self begin(const GraphT& G) { return _Self(GT::getEntryNode(G)); } + static inline _Self end (const GraphT& G) { return _Self(); } // Direct loop termination test (I.fini() is more efficient tha...

...==== --- include/llvm/ADT/SCCIterator.h (revision 88920) +++ include/llvm/ADT/SCCIterator.h (working copy) @@ -135,8 +135,8 @@ typedef scc_iterator<GraphT, GT> _Self; // Provide static "constructors"... - static inline _Self begin(GraphT& G) { return _Self(GT::getEntryNode(G)); } - static inline _Self end (GraphT& G) { return _Self(); } + static inline _Self begin(const GraphT& G) { return _Self(GT::getEntryNode(G)); } + static inline _Self end (const GraphT& G) { return _Self(); } // Direct loop termination test (I.fini() is more efficient tha...

Hi, I am using the scc_iterator class in my code on a CallGraph, where some functions are not called from within the module. It seems that scc_iterator does not list all SCCs if the graph is not connected; only those nodes connected to the node pointed to by GraphTraits<...>::getEntryNode() are returned. Can someone verify this behavior? Any tips on how I should go about extending the class in order to visit all SCCs? Is it desirable to augment the scc_iterator class itself, or should I construct another one? The change in behavior may impact things such as CallGraphSCCPass, Gl...

Dan Gohman wrote: > There certainly are wishlist items for TableGen and TableGen-based > instruction descriptions, though I don't know of an official list. > Offhand, > a few things that come to mind are the ability to handle nodes with > multiple results, Is there an official workaround, BTW? - Volodya

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

...erator.h (revision 76093) > +++ include/llvm/ADT/SCCIterator.h (working copy) > @@ -135,8 +135,8 @@ > typedef scc_iterator<GraphT, GT> _Self; > > // Provide static "constructors"... > - static inline _Self begin(GraphT& G) { return > _Self(GT::getEntryNode(G)); } > - static inline _Self end (GraphT& G) { return _Self(); } > + static inline _Self begin(const GraphT& G) { return > _Self(GT::getEntryNode(G)); } > + static inline _Self end (const GraphT& G) { return _Self(); } > > // Direct loop termination test (I.f...

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

...e scc_iterator class in my code on a CallGraph, where > some > functions are not called from within the module. It seems that > scc_iterator does not list all SCCs if the graph is not connected; > only > those nodes connected to the node pointed to by > GraphTraits<...>::getEntryNode() are returned. > > Can someone verify this behavior? > Any tips on how I should go about extending the class in order to > visit > all SCCs? > Is it desirable to augment the scc_iterator class itself, or should I > construct another one? The change in behavior may impact th...

...ster I’d really like to be able to do this at the IR level. What I want to do is write a custom lowering hook to convert ISD::ATOMIC_LOAD into a standard ISD::LOAD with the save/restore/interrupt nodes glued to it. Here’s what I have so far: // Store `SREG` auto Save = DAG.getCopyFromReg(DAG.getEntryNode(), DL, AVR::SREG, MVT::i8); // Disable interrupts (`clr` is equivalent to `bclr 7`). auto ClearInterrupts = DAG.getNode(AVRISD::BCLR, DL, MVT::Glue, DAG.getConstant(7, DL, MVT::i8)); // Perform the nonatomic load. auto *Node = cast<AtomicSDNode>(AtomicOp.getNode()); SDValue Load...

...scc_iterator class in my code on a CallGraph, where some >> functions are not called from within the module. It seems that >> scc_iterator does not list all SCCs if the graph is not connected; only >> those nodes connected to the node pointed to by >> GraphTraits<...>::getEntryNode() are returned. >> >> Can someone verify this behavior? >> Any tips on how I should go about extending the class in order to visit >> all SCCs? >> Is it desirable to augment the scc_iterator class itself, or should I >> construct another one? The change in behav...

...----------------------------- const Type *OpNTy = MVT::getTypeForValueType(MVT::i32); Constant *C = ConstantUInt::get(OpNTy, t); int alignment = 2; SDOperand Addr = CurDAG->getTargetConstantPool(C, MVT::i32, alignment); Arg = CurDAG->getLoad(MVT::i32, CurDAG->getEntryNode(), Addr, CurDAG->getSrcValue(NULL)); ---------------------------------------------------------------------------------------- This fails with the assert "This target-independent node should have been selected". It is illegal to create a load during select...

Thanks, that sounds like it would work. Was this based on what any other target did? Or do any other targets take this approach? I just want to make sure that we don't already have a hook suitable for this. Overriding runOnFunction to run what could be described as just a "late SelectionDAG pass" sounds pretty intrusive. Do you remember other approaches that didn't work? --

...et->is64Bit()) { idReg = X86::RCX; resultReg = X86::RAX; } else { idReg = X86::ECX; resultReg = X86::EAX; } idRegValue = CurDAG->getRegister(idReg, resultType); SmallVector<SDValue, 8> Ops; SDValue setIdNode = CurDAG->getCopyToReg(CurDAG->getEntryNode(), dl, idRegValue, id, SDValue()); SDValue rdmsrNode = SDValue(CurDAG->getMachineNode(X86::RDMSR, dl, MVT::Other, setIdNode), 0); SDValue resultNode = CurDAG->getCopyFromReg(rdmsrNode, dl, resultReg, resultType); Ops.push_back(resultNode); Ops.push_back(rdmsrNode); Ops.push_b...

...following predecessor edges) for a liveness analysis I'm writing. idf_iterator seems like it's almost the class I need, but it starts at the first block in the function at present, rather than the last one (because of the specialisiation of GraphTraits for Inverse<MachineFunction*> - getEntryNode returns mf->front()). That seems odd to me - you can only ever get to the first block with it (incrementing the iterator once yields idf_end(mf), and there's no decrement operation). Is this behaviour intentional? If it is I'll need to write some inverse iteration functions myself. Is...

...Op1, Op2), 0); // Copy the low half of the result, if it is needed. if (!SDValue(N, 0).use_empty()) { SDValue Result = CurDAG->getCopyFromReg(CurDAG->getEntryNode(), dl, LoReg, NVT, InFlag); InFlag = Result.getValue(2);...

On Sep 9, 2010, at 12:59 PM, Borja Ferrer wrote: > Hello, i've noticed a new possible missed optimization while testing more trivial code. > This time it's not a with a xor but with a multiplication instruction and the example is little bit more involved. > > C code: > > typedef short t; > t foo(t a, t b) > { > t a4 = a*b; > return a4; > } >

...ill, perform the spill. > SDValue SpillVal = Node->getOperand(OpNo); > SDValue SpillSlot = CurDAG->CreateStackTemporary(SpillVal.getValueType()); > int FI = cast<FrameIndexSDNode>(SpillSlot)->getIndex(); > SDValue Chain = CurDAG->getStore(CurDAG->getEntryNode(), > SpillVal.getDebugLoc(), > SpillVal, SpillSlot, > MachinePointerInfo::getFixedStack(FI), > false, false, 0); > Chain = CurDAG-...

...sal when finding the SCCs in the call graph. I'm basing my implementation for the GraphTraits for the ModuleSummaryIndex off the GraphTraits<CallGraph *> implementation ( http://llvm-cs.pcc.me.uk/include/llvm/Analysis/CallGraph.h#407). In the GraphTrait<CallGraph *> definition, the getEntryNode function returns the external calling node ( http://llvm-cs.pcc.me.uk/include/llvm/Analysis/CallGraph.h#450), which I assume is supposed to be at the bottom of the callgraph. Would doing same for the ModuleSummaryIndex ensure the scc_iterator traverses bottom up (if that even makes sense)? Rather...

...ConstantSDNode *ConstNode = cast<ConstantSDNode>(Node); // Materialize zero constants as copies from R0. This allows the coalescer // to propagate these into other instructions. if (ConstNode->isNullValue()) { SDValue New = CurDAG->getCopyFromReg(CurDAG->getEntryNode(), SDLoc(Node), Lanai::R0, MVT::i32); return ReplaceNode(Node, New.getNode()); } // Materialize all ones constants as copies from R1. This allows the // coalescer to propagate these into other instructions. if (ConstNode-...

...6::RCX; resultReg = MF.addLiveIn(X86::RAX, &X86::GR64RegClass); } else { idReg = X86::ECX; resultReg = MF.addLiveIn(X86::EAX, &X86::GR32RegClass); } idRegValue = CurDAG->getRegister(idReg, resultType); SDValue setIdNode = CurDAG->getCopyToReg(CurDAG->getEntryNode(), dl, idRegValue, id, SDValue()); SDValue rdmsrNode = SDValue(CurDAG->getMachineNode(X86::RDMSR, dl, MVT::Glue, setIdNode.getValue(1)), 0); SDValue resultNode = CurDAG->getCopyFromReg(CurDAG->getEntryNode(), dl, X86::EAX, MVT::i32, rdmsrNode); return resultNode.getNode(); b...