search for: ilist

Hi All, I have just started using LLVM . i am facing a issue while using ilist container. Here is a struct with ilist container as its one element. typedef ilist<Instruction *> InstListType; struct list_node { int Impact; InstListType InstList; };...

...ock, I first get all instructions in my basic block in an instruction container list. Once that is done, I insert my new instruction in the instruction container list using InstList.insert(). // code void FSliceModulePass::allocaVSetArray(void) { auto &B = F->getEntryBlock(); auto &IList = B.getInstList(); auto &FirstI = *IList.begin(); auto TaintVar = new AllocaInst(IntPtrTy, FirstI); IList.insert(FirstI, TaintVar); // ERROR After migrating to 3.8.1, It gives me the following error: ERROR: /home/shehbaz/project/plugin/FSlice.cpp: In member function ‘void FSliceModu...

..., 2015 at 11:13 AM, Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2015-Oct-07, at 17:57, Duncan P. N. Exon Smith <dexonsmith at apple.com> > wrote: > > > > I've been digging into some undefined behaviour stemming from how ilist > > is typically configured. r247937, r247944, and r247978 caused a UBSan > > failure to start firing on our Green Dragon bots, and after an IRC > > conversation between David and Nick and Mehdi, we added a blacklist: > > -- > > $echo "src:$WORKSPACE/llvm/include...

...writes: >> On 2015-Oct-20, at 11:23, Reid Kleckner <rnk at google.com> wrote: >> >> I think the implicit iterator conversions are much less important >> now that we have range based for loops, but I still like having >> them. > > IMO, if a developer has an ilist iterator and wants a pointer, they > should explicitly use `&*I` to make the assumption that "`I` isn't the > end iterator" explicit in the code. Similarly, in the other direction, > `N->getIterator()` makes it clear that `N` is definitely not `nullptr` > and is th...

...g on the x86 machine because of a segmentation fault) Both builds were done using: g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4) Something should be wrong with my environment... The only differences I noticed during the compilation are the following warnings (which appear several times, but each time in ilist.h): llvm-2.9/include/llvm/ADT/ilist.h: In member function ‘virtual bool<unnamed>::AAEval::runOnFunction(llvm::Function&)’: llvm-2.9/include/llvm/ADT/ilist.h:175: warning: ‘this.581’ is used uninitialized in this function llvm-2.9/include/llvm/ADT/ilist.h:175: note: ‘this.581’ was declared...

...(this=0x8147000, __in_chrg=<value optimized out>) at /x/grwright/llvm/llvm-2.9/lib/VMCore/Instruction.cpp:54 #11 0xf7275461 in ~GetElementPtrInst (this=0x8147000, __in_chrg=<value optimized out>) at /x/grwright/llvm/llvm-2.9/include/llvm/Instructions.h:285 #12 0xf7136671 in llvm::ilist_node_traits<llvm::Instruction>::deleteNode (V=0x8147000) at /x/grwright/llvm/llvm-2.9/include/llvm/ADT/ilist.h:112 #13 0xf7135c80 in llvm::iplist<llvm::Instruction, llvm::ilist_traits<llvm::Instruction> >::erase (this=0x8145d14, where=...) at /x/grwright/llvm/llvm-2.9/inclu...

...z Jaffer via llvm-dev wrote: >> >> I tried an alternative way of adding instruction by first getting the >> first instruction of the basic block, and then calling insertAfter() >> on it as follows: >> >> auto &B = F->getEntryBlock(); >> auto &IList = B.getInstList(); >> auto &FirstI = *IList.begin(); >> auto TaintVar = new AllocaInst(IntPtrTy); >> // IList.insert(FirstI, TaintVar); // OLD >> FirstI.insertAfter(TaintVar); // NEW > > > You want: > > TaintVar->insertAfter(FirstI);...

I've been digging into some undefined behaviour stemming from how ilist is typically configured. r247937, r247944, and r247978 caused a UBSan failure to start firing on our Green Dragon bots, and after an IRC conversation between David and Nick and Mehdi, we added a blacklist: -- $echo "src:$WORKSPACE/llvm/include/llvm/CodeGen/MachineFunction.h" >> san...

...gt; out>) at /x/grwright/llvm/llvm-2.9/lib/VMCore/Instruction.cpp:54 #11 >> 0xf7275461 in ~GetElementPtrInst (this=0x8147000, __in_chrg=<value >> optimized out>) at >> /x/grwright/llvm/llvm-2.9/include/llvm/Instructions.h:285 #12 0xf7136671 >> in >> llvm::ilist_node_traits<llvm::Instruction>::deleteNode (V=0x8147000) at >> /x/grwright/llvm/llvm-2.9/include/llvm/ADT/ilist.h:112 #13 0xf7135c80 in >> llvm::iplist<llvm::Instruction, llvm::ilist_traits<llvm::Instruction> >>> ::erase (this=0x8145d14, >> >> where=....

...gt; > optimized > > out>) at /x/grwright/llvm/llvm-2.9/lib/VMCore/Instruction.cpp:54 #11 > 0xf7275461 in ~GetElementPtrInst (this=0x8147000, __in_chrg=<value > optimized out>) at > /x/grwright/llvm/llvm-2.9/include/llvm/Instructions.h:285 #12 0xf7136671 in > llvm::ilist_node_traits<llvm::Instruction>::deleteNode (V=0x8147000) at > /x/grwright/llvm/llvm-2.9/include/llvm/ADT/ilist.h:112 #13 0xf7135c80 in > llvm::iplist<llvm::Instruction, llvm::ilist_traits<llvm::Instruction> >> ::erase (this=0x8145d14, > > where=...) > > a...

...loop invariant instructions to the loop preheader. When I process the instructions backward as shown in the following code, I got the following error right after the "hoist(I)" is done. Can anyone advise whether I am misusing BasicBlock::iterator? /opt/llvms/src/llvm_26/ include/llvm/ADT/ilist.h:213: llvm::ilist_iterator<NodeTy>& llvm::ilist_iterator<NodeTy>::operator--() [with NodeTy = llvm::Instruction]: Assertion `NodePtr && "--'d off the beginning of an ilist!"' failed. *LICM::HOistRegion(DomTreeNode *N)* { assert(N != 0 && &quo...

...uction (this=0x8147000, __in_chrg=<value optimized out>) at /x/grwright/llvm/llvm-2.9/lib/VMCore/Instruction.cpp:54 #11 0xf7275461 in ~GetElementPtrInst (this=0x8147000, __in_chrg=<value optimized out>) at /x/grwright/llvm/llvm-2.9/include/llvm/Instructions.h:285 #12 0xf7136671 in llvm::ilist_node_traits<llvm::Instruction>::deleteNode (V=0x8147000) at /x/grwright/llvm/llvm-2.9/include/llvm/ADT/ilist.h:112 #13 0xf7135c80 in llvm::iplist<llvm::Instruction, llvm::ilist_traits<llvm::Instruction> >::erase (this=0x8145d14, where=...) at /x/grwright/llvm/llvm-2.9/include/llvm...

On Apr 26, 2011, at 4:44 PM, Damien Vincent wrote: > > I am testing the latest LLVM release (2.9). > When I run the regression tests, I get many failures: > > cd llvm-2.9.build/test > make > Expected Passes : 2605 > Expected Failures : 46 > Unsupported Tests : 542 > >>> Unexpected Failures: 2658 > > For info: > - I was working with

Hi all, Two days ago MachineBasicBlock got ilistified. What does this mean and how does it affect you? Read on. MachineBasicBlock used to have a std::vector<MachineInstr*> to represent the instructions it constisted of. This representation has the following problems: 1) O(n) insertions/removals to/from anywhere but the end of a bas...

...m using the following version of BuildMI : MachineInstrBuilder BuildMI(MachineFunction &MF, const TargetInstrDesc &TID, unsigned DestReg) I do the following : void createInstrs(std::vector<MachineInstr *>& ilist) { Machine Instr *mi; mi = BuildMI(MF, someTID, somereg); ilist.push_back(mi); mi = BuildMI(MF, someotherTID, someotherreg); ilist.push_back(mi); } viud insertInto(MachineBasicBlock *BB, MachineBasicBlock::iterator II) { std::vector<MachineInstr *> temp; createInstrs(temp);...

I am testing the latest LLVM release (2.9). When I run the regression tests, I get many failures: cd llvm-2.9.build/test make Expected Passes : 2605 Expected Failures : 46 Unsupported Tests : 542 >>> Unexpected Failures: 2658 For info: - I was working with 2.8 so far and I didn't have these issues. - LLVM was build using: ../llvm-2.9/configure --enable-assertions

...I probably won`t submit that, at least not in its present form -- maybe in a much-more-limited form that doesn`t need the sorting. However, I thought this sorting code might be useful to somebody else, so here it is for feedback. Maybe somebody wants to add the needed glue code so e.g. "my_ilist.sort()" will call the below rather than invoking the relevant ancestor-class "sort()" and crashing? If so, then ditto for e.g. "my_ilist.sort(my_comparator)", please. Regards, Abe ===== snippet from altered "llvm/include/llvm/ADT/ilist.h" ===== ===== c...

...of a > segmentation fault) > Both builds were done using: g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4) > Something should be wrong with my environment... > > The only differences I noticed during the compilation are the following > warnings (which appear several times, but each time in ilist.h): > llvm-2.9/include/llvm/ADT/ilist.h: In member function ‘virtual > bool<unnamed>::AAEval::runOnFunction(llvm::Function&)’: > llvm-2.9/include/llvm/ADT/ilist.h:175: warning: ‘this.581’ is used > uninitialized in this function > llvm-2.9/include/llvm/ADT/ilist.h:175: note...

...ge details here. Would you mind explaining in more detail what the problem is specifically, and what we should be doing to avoid this issue in the future? Using something like "&*I" in the LDCleanup file wouldn't have naturally occurred to me ... :-) > See PR26753 and "ilist/iplist are broken (maybe I'll fix them?)": http://lists.llvm.org/pipermail/llvm-dev/2015-October/091115.html I thought I was "finished" back in November, but I'd forgotten about MachineInstrBundleIterator (MachineBasicBlock::iterator) and then didn't find time to conti...

Hi Gang-Ryung! Your reverse iteration of instructions in the BB > * for (BasicBlock::iterator II = BB->end(); II != BB->begin(); ) *{ > > Instruction &I = *--II; > > if (isLoopInvariantInst(I) && canSinkOrHoistInst(I) && > isSafeToExecuteUnconditionally(I)) > * hoist(I);* >