search for: pop_back

...mation change across callsites? Isn't a good context-insensitive function summary good enough? It changes all the time. Here’s a trivial example, assume no inlining and no AA other than the one in question: std::vector<int> V1 = { 1, 2, 3 }; std::vector<int> V2 = { 4, 5, 6 }; V1.pop_back(); // Mutates *this auto length = V1.size(); V2.pop_back(); // Mutates *this auto zero = length - V1.size() In this case, the compiler should “obviously” be able to CSE length, allowing further simplification to substitute zero with 0. However, with a context sensitive AA, both &V1 a...

On 03/25/2016 08:08 PM, Chris Lattner wrote: > I’m still a big fan of context sensitive, flow insensitive, > unification based models. Interestingly I find the unification approach quite unsatisfactory sometime. What happens there is pointers with the same "depth" are too often clobbered together unless they are really unrelated to each other. > Contrary to your claim,

...anges all the time. Here’s a trivial example, assume no > > inlining > > and no AA other than the one in question: > > > > std::vector<int> V1 = { 1, 2, 3 }; > > > > > > std::vector<int> V2 = { 4, 5, 6 }; > > > > > > V1.pop_back(); // Mutates *this > > > > > > auto length = V1.size(); > > > > > > V2.pop_back(); // Mutates *this > > > > > > auto zero = length - V1.size() > > > > > In this case, the compiler should “obviously” be able to CSE >...

On 03/28/2016 12:37 AM, Chris Lattner wrote: > It changes all the time. Here’s a trivial example, assume no inlining > and no AA other than the one in question: > > std::vector<int> V1 = { 1, 2, 3 }; > std::vector<int> V2 = { 4, 5, 6 }; > > V1.pop_back(); // Mutates *this > > auto length = V1.size(); > > V2.pop_back(); // Mutates *this > > auto zero = length - V1.size() > > > In this case, the compiler should “obviously” be able to CSE length, > allowing further simplification to substitute zero wi...

...er wrote: > > It changes all the time. Here’s a trivial example, assume no > inlining and no AA other than the one in question: > > std::vector<int> V1 = { 1, 2, 3 }; > std::vector<int> V2 = { 4, 5, 6 }; > > V1.pop_back(); // Mutates *this > > auto length = V1.size(); > > V2.pop_back(); // Mutates *this > > auto zero = length - V1.size() > > > Can you elaborate on what you mean by flow sensitive? We have a > mod/ref query interface that can r...

Sorry, this is the part in ARMLoadStoreOptimizer.cpp that creates a LDRD instruction. Ops.pop_back(); Ops.pop_back(); // Form the pair instruction. if (isLd) { MachineInstrBuilder MIB = BuildMI(*MBB, InsertPos, dl, TII->get(NewOpc)) .addReg(EvenReg, RegState::Define) .addReg(Odd...

...t char* t1 = parse_expression(t, last, db); if (t1 != t) { if (db.names.size() < 2) return first; - auto expr = db.names.back().move_full(); + auto from_expr = db.names.back(); db.names.pop_back(); if (db.names.empty()) return first; - db.names.back() = "const_cast<" + db.names.back().move_full() + ">(" + expr + ")"; + db.names.back() = db.template make<cast_expr>( +...

On Sep 7, 2010, at 10:48 AM, Akira Hatanaka wrote: > I have two questions regarding MachineMemOperands and dependence information. > > Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. > > (before optimization) > %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0;

I have two questions regarding MachineMemOperands and dependence information. Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. (before optimization) %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%uglygep10] %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14,

...erl ones.) > > I agree, but for consistency I thought it was better to keep those > names rather than trying to think up new ones which would be different > from everything else. Actually I forgot that C++ (STL vector, deque etc) have functions called push_front, pop_front, push_back, pop_back. Don't know if that would be better. Is it obvious what front and back mean? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://lib...

...d setEnd(T *P) { this->EndX = P; } (gdb) where #0 0x0099be14 in llvm::SmallVectorTemplateCommon<llvm::SDNode*>::setEnd (this=0x7ee90b38, P=0x5c06988) 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::is...

Hi there, I haven't been on this list until now, so I wasn't aware of this problem until last night ;-) - sorry for that. I am working on a patch for oggCut for that issue (looks good actually but I would like to do some testing befor I can release a patch.) Normal players are not effected by the page time misordering, so I took this issue as "minor". The reason for the

...for ownsModule. However, the hasModuleBeenAdded functionality is required to avoid duplicate search in getPointerToFunction. As you note the name is wrong, I renamed the function to hasModuleBeenAddedButNotLoaded and cleaned the logic at getPointerToFunction() to minimize searches for all cases. pop_back() vs. clear() - since I knew there is one module only (we override the AddModule so EE can't get another) that what "popped" into my mind. clear() is just as good, changed. EE, JIT, MCJIT inheritance - the interpreter and the JIT would also benefit from a SmallPtrSet module manager r...

...loaded or finalized has also been added. Your implementation checks "has been added but not loaded" but it doesn't seem like that's necessary anywhere. Can you eliminate this function and just use OwningModuleContain::ownsModule? Second, why did you decide to use "Modules.pop_back()" in the MCJIT destructor rather than "Modules.clear()"? I expect there will only be one module that makes it into that list so they should be functionally equivalent, but calling "clear" seems to better indicate the intention. Also, in the same place, I think "don&...

...ndX = P; } > (gdb) where > #0  0x0099be14 in llvm::SmallVectorTemplateCommon<llvm::SDNode*>::setEnd > (this=0x7ee90b38, >     P=0x5c06988) 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  0x00...

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

Hi Andy, Here is the patch. it incorporates: 1) your latest patch to SVN. 2) mcjit-module-state-optimization.patch. 3) the PtrSet changes. Other than the OwnedModules implementation there were other differences between 1) and 2), especially in the Finalize* functions, so please review that I got the right code. I got bitten by subtle bugs arising from MCJIT inheriting from EE: First, MCJIT

...+ let h = Hashtbl.create (List.length xs) in + let rec loop = function + | [] -> [] + | x :: xs when Hashtbl.mem h x -> xs + | x :: xs -> Hashtbl.add h x true; x :: loop xs + in + loop xs + let push_back xsp x = xsp := !xsp @ [x] let push_front x xsp = xsp := x :: !xsp let pop_back xsp = diff --git a/mllib/common_utils.mli b/mllib/common_utils.mli index 68c0d54..ad43345 100644 --- a/mllib/common_utils.mli +++ b/mllib/common_utils.mli @@ -147,6 +147,12 @@ val uniq : ?cmp:('a -> 'a -> int) -> 'a list -> 'a list val sort_uniq : ?cmp:('a -> ...

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

...y the reason why Mapvector did not have erase before. See http://llvm.org/docs/ProgrammersManual.html#llvm-adt-mapvector-h ...and it doesn't support removing elements. To correct this erase needs to decrement all vector indices in the Map which are larger than the removed index. Note that pop_back() does not have this problem as there are no indices following the last one. Yaron 2014-07-15 17:35 GMT+03:00 Oliver Stannard <oliver.stannard at arm.com>: > Do you have a reproducer for this problem? MapVector::erase removes the > value from both the Vector and the Map, so it shou...