search for: pop_back_v

Hi, Here is the code in IndVarSimplify.cpp. SmallVector<WeakVH, 16> DeadInsts; while (!DeadInsts.empty()) if (Instruction *Inst = dyn_cast_or_null<Instruction>(&*DeadInsts.pop_back_val())) RecursivelyDeleteTriviallyDeadInstructions(Inst, TLI); Since DeadInsts.pop_back_val() is WeakVH which could hold a NULL pointer, the expression, &*DeadInsts.pop_back_val(), could be &*NULL. Then NULL pointer is dereferenced here. I wrote a small test case and it works just fin...

Thank you David for prompt reply. I tried with SmallVector. I inserted elements with push_back(). But when I retrieve elements using pop_back_val the elements are returned in reverse order of insertion (I mean like LIFO order). I need this to be FIFO order. How to achieve that? Regards, Rekha On Sun, Nov 3, 2013 at 8:31 PM, David Blaikie <dblaikie at gmail.com> wrote: > If you don't care about efficiency you can push (or a...

Hi, I am writing an analysis which requires creating worklist of basic blocks. The worklist should be in FIFO order. I checked SmallVector (and similar others) and found out this is working in LIFO order when I use the functions push_back and pop_back_val to insert and delete elements in the worklist. Can someone suggest an appropriate DS to implement my worklist. Note: I am not concerned about efficiency here. -- Regards, Rekha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/l...

On Sun, Nov 3, 2013 at 7:38 AM, Rekha R <rekharamapai at nitc.ac.in> wrote: > Thank you David for prompt reply. > > I tried with SmallVector. I inserted elements with push_back(). > But when I retrieve elements using pop_back_val the elements are returned > in reverse order of insertion (I mean like LIFO order). > I need this to be FIFO order. How to achieve that? > push_back and pop_back both act on the "back" or "end" of the vector, so you'll get LIFO behavior if you use them in that wa...

...at nitc.ac.in> wrote: > Hi, > > I am writing an analysis which requires creating worklist of basic blocks. > The worklist should be in FIFO order. I checked SmallVector (and similar > others) and found out this is working in LIFO order when I use the > functions push_back and pop_back_val to insert and delete elements in the > worklist. > > Can someone suggest an appropriate DS to implement my worklist. Note: I am > not concerned about efficiency here. > > -- > Regards, > Rekha > > _______________________________________________ > LLVM Developers m...

...at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:103 #1 0x00a4849c in llvm::SmallVectorImpl<llvm::SDNode*>::pop_back (this=0x7ee90b38) at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:334 #2 0x00a483b8 in llvm::SmallVectorImpl<llvm::SDNode*>::pop_back_val (this=0x7ee90b38) at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:340 #3 0x00a6f074 in llvm::SDNode::isPredecessorOf (this=0x641bb08, N=0x6212a40) at /export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5703 #4 0x00a057c8 in CombineToPreInde...

...on *I = &*FI; ++FI; // We're visiting this instruction now, so make sure it's not in the // worklist from an earlier visit. WorkList.remove(I); MadeChange |= simplifyAndDCEInstruction(I, WorkList, DL); } while (!WorkList.empty()) { Instruction *I = WorkList.pop_back_val(); MadeChange |= simplifyAndDCEInstruction(I, WorkList, DL); } return MadeChange; } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150913/9bde4a5d/attachment-0001.html>

...arel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:103 > #1  0x00a4849c in llvm::SmallVectorImpl<llvm::SDNode*>::pop_back > (this=0x7ee90b38) >     at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:334 > #2  0x00a483b8 in llvm::SmallVectorImpl<llvm::SDNode*>::pop_back_val > (this=0x7ee90b38) >     at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:340 > #3  0x00a6f074 in llvm::SDNode::isPredecessorOf (this=0x641bb08, > N=0x6212a40) >     at > /export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5703 > #4  ...

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

...pr &CExprToCollapse, + SmallVectorImpl<Edge> &Results) { + SmallVector<ConstantExpr*, 4> Worklist; + Worklist.push_back(&CExprToCollapse); + + SmallVector<Edge, 8> ConstexprEdges; + while (!Worklist.empty()) { + auto* CExpr = Worklist.pop_back_val(); + std::unique_ptr<Instruction> Inst(CExpr->getAsInstruction()); + + ConstexprEdges.clear(); + argsToEdges(Analysis, Inst.get(), ConstexprEdges); + for (auto& Edge : ConstexprEdges) { + assert(Edge.From == Inst.get() && + "Expected ConstantExp...

I’ve been playing around with optimizing performance various passes and noticed something about ADCE: it keeps an Alive set that requires a lot of upkeep time-wise, but if each instruction had a /single bit/ of side data (to represent liveness, solely within the pass), the set wouldn’t be needed. I tested this out and observed a ~1/3 reduction in time in ADCE: 1454ms to 982ms according to a

...Expr>(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<GlobalValue>(CurValue)) + if (canSkipAddingToSets(CurValue)) continue; for (const auto &EdgeTuple : Graph.edgesFor(Node)) { @@ -902,7 +915,7 @@ static Functio...

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >

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

...t *C = dyn_cast<Constant>(*op)) { + if (!isa<BasicBlock>(C) && Visited.find(C) == Visited.end()) { + Visited[C] = true; + WorkList.push_back(C); + } + } + } + } + + while(!WorkList.empty()) { + Constant *C = WorkList.pop_back_val(); + if (GlobalVariable *GV = dyn_cast<GlobalVariable>(C)) { + if (VMap.find(GV) == VMap.end()) { + VMap[GV] = CreateVarDecl(GV, New); + PromoteGlobalVarLinkage(GV); + } + continue; + } else if (Function *Func = dyn_cast<Function>(C)) {...

...ced on the safe stack. + + SmallPtrSet<const Value*, 16> Visited; + SmallVector<const Instruction*, 8> WorkList; + WorkList.push_back(AI); + + // A DFS search through all uses of the alloca in bitcasts/PHI/GEPs/etc. + while (!WorkList.empty()) { + const Instruction *V = WorkList.pop_back_val(); + for (Value::const_use_iterator UI = V->use_begin(), + UE = V->use_end(); UI != UE; ++UI) { + const Instruction *I = cast<const Instruction>(UI->getUser()); + assert(V == UI->get()); + + switch (I->getOpcode()) { +...