search for: inst_iterator

...all. In particular ilists have some funny > semantics that you should know about. In particular, the instruction list > is more like a std::list<Instruction> (but that allows polymorphism) than > a std::list<Instruction*>, Yea, I've noticed that. However, it looks like inst_iterator is iterator over pointers. Oh, wait a minite, that's the current code: inline IIty operator*() const { return BI; } inline IIty operator->() const { return operator*(); } So operator* works as if value_type is Instruction*, but operator-> works as if value_type is Instruction. Hm...

On Fri, 23 Apr 2004, Vladimir Prus wrote: > Yea, I've noticed that. However, it looks like inst_iterator is iterator over > pointers. Oh, wait a minite, that's the current code: > > inline IIty operator*() const { return BI; } > inline IIty operator->() const { return operator*(); } > > So operator* works as if value_type is Instruction*, but operator-> works as > i...

...ator*(); } > > > > So operator* works as if value_type is Instruction*, but operator-> works > > as if value_type is Instruction. Hmm ;-) > > Yeah, fishy huh? :) Yea, a bit. I've decided that before changing that I'd better find other problems, if any, so I run inst_iterator via checks provided by Boost.Iterators. First problem is that inst_iterator (and actually InstIterator class template) is not Assignable, because it has a reference data member, while standard requires all iterators to be assignable. Second InstIterator is not DefaultConstructile, which is req...

...the reply. What about instruction ordering across basic >> blocks? Let's say instructions IA and IB belong to basic blocks BBa >> and BBb, where BBa is before BBb in program order. Then, will IA be >> printed before IB? > > Yes, llvm-dis does print in the same order that inst_iterator visits. > The llvm::Function has a linked list of llvm::BasicBlock objects. Both > llvm-dis and the inst_iterator will iterate over that list, and then > for each basic block iterate over the linked list of llvm::Instruction > objects. Both of these lists are ordered, and their orde...

...cks? Let's say instructions IA and IB belong to basic blocks BBa and BBb, where BBa is before BBb in program order. Then, will IA be printed before IB? Anirudh > -- > Mats > > On 15 June 2015 at 18:10, Anirudh Sivaraman <sk.anirudh at gmail.com> wrote: >> >> Does inst_iterator >> >> (http://llvm.org/docs/ProgrammersManual.html#iterating-over-the-instruction-in-a-function) >> guarantee that the iterated instructions are in program order: the >> order of instructions printed by llvm-dis? >> >> Thanks in advance, >> Anirudh >>...

...hat I found I may or may not insert code. Despite the fact that I'm > only actually inserting *before* instruction I have a infinite loop > when I do something like below. For awhile it was simple enough to > just increment i enough times but now I need something better. > > for(inst_iterator i = inst_begin(F); i != inst_end(F); ++i) { > ... > // possible insertions of unknown size > ... > } > > I tried storing the storing the initial iterator and reverting back to > it(along with storing the next element) and I am still left with a > inf...

Hello, I think there's a rather subtle problem with the inst_iterator. It declares its iterator category as std::bidirectional_iterator_tag but C++ standard requirements for forward iterator (which are included in requirements for bidirection iterator), say that the type of expression *r; should be T&, where 'r' is the iterator and T is its value...

...list<Instruction> (but that allows polymorphism) than a std::list<Instruction*>, so it's not possible to just assign a new instruction* through an iterator. In other words: *iit = new Instruction(...) doesn't make any sense. Probably the right thing to do would be to make the inst_iterator return a reference to the *instruction* itself, rather than a reference to the pointer. This would make it work the same as standard ilist iterators. The reason why we have it return pointers right now is to populate worklists, which allows us to do: std::set<Instruction*> WorkList(inst_beg...

Does inst_iterator (http://llvm.org/docs/ProgrammersManual.html#iterating-over-the-instruction-in-a-function) guarantee that the iterated instructions are in program order: the order of instructions printed by llvm-dis? Thanks in advance, Anirudh

...nction and depending on what I found I may or may not insert code. Despite the fact that I'm only actually inserting *before* instruction I have a infinite loop when I do something like below. For awhile it was simple enough to just increment i enough times but now I need something better. for(inst_iterator i = inst_begin(F); i != inst_end(F); ++i) {         ...        // possible insertions of unknown size         ... } I tried storing the storing the initial iterator and reverting back to it(along with storing the next element) and I am still left with a infinite loop. I see some discussion online...

On Tue, 27 Apr 2004, Vladimir Prus wrote: > > Yeah, fishy huh? :) > > Yea, a bit. I've decided that before changing that I'd better find other > problems, if any, so I run inst_iterator via checks provided by > Boost.Iterators. > > First problem is that inst_iterator (and actually InstIterator class template) > is not Assignable, because it has a reference data member, while standard > requires all iterators to be assignable. Ok. > Second InstIterator is not De...

...what I found I may or may not insert code. Despite the fact that I'm > only actually inserting *before* instruction I have a infinite loop > when I do something like below. For awhile it was simple enough to > just increment i enough times but now I need something better. > > for(inst_iterator i = inst_begin(F); i != inst_end(F); ++i) { > ... > // possible insertions of unknown size > ... > } > > I tried storing the storing the initial iterator and reverting back to > it(along with storing the next element) and I am still left with a > infi...

> When I'm iterating through I only directly add BitCastInsts and a > single CallInst(Im assuming the functions I also created are > elsewhere). Unfortunately it doesnt look like theres is a good way to > convert between the the iterator I and a CallInst *. Am I missing > something? > I'm not entirely sure how this relates to my explanation/suggestion. How does your

...hey are not I would like to call a function. I've tried splitting the current block and then inserting before the existing instructions, but for some reason this seems to ruin the iterator(i). What is the correct way todo something like this? void checkShadowPtr(Module &M, Function &F, inst_iterator i, GlobalVariable *shadow, Value *val) { /* Split old Block */ BasicBlock *bb = i->getParent(); BasicBlock *bb_after = i->getParent()->splitBasicBlock(&*i); bb->getTerminator()->eraseFromParent(); /* Test */ ICmpInst *test = new ICmpInst(*bb, CmpInst::ICMP_NE, shad...

...r may not insert code. Despite the fact that I'm >> only actually inserting *before* instruction I have a infinite loop >> when I do something like below. For awhile it was simple enough to >> just increment i enough times but now I need something better. >> >> for(inst_iterator i = inst_begin(F); i != inst_end(F); ++i) { >>         ... >>         // possible insertions of unknown size >>         ... >> } >> >> I tried storing the storing the initial iterator and reverting back to >> it(along with storing the next element) and I am...

...gt; call a function. I've tried splitting the current block and then > inserting before the existing instructions, but for some reason this > seems to ruin the iterator(i). What is the correct way todo something > like this? > > void checkShadowPtr(Module &M, Function &F, inst_iterator i, > GlobalVariable *shadow, Value *val) { inst_iterator is hiding iterators which aren't going to stay consistent across this kind of change. I'd suggest explicitly using Function::iterator and BasicBlock::iterator to keep track of where you are in the function; that should make it ob...

...ructions in Function (error Hi, Please find the embedded code. Also you may follow http://llvm.org/docs/ProgrammersManual.html#iterating-over-the-instruction-in-a-function - Sandeep I have following lines in my code, where I need to iterate over the instructions in the function (not BB): for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I){ Instruction *Inst = I; Instruction *Inst = &*I; if (Inst -> getOpcode() == Instruction::GetElementPtr){ Value* AddrPointer = Inst->getIperand(0); .... if (cast<Operator>(Inst) -> getOpcode() == Instruction...

I'm trying to come up with a simple example of using ICmpInst in a Pass. On each of the branches(true, false) I'd like to call a separate function and then resume(to the code that was already there). In this example i is a inst_iterator to Instruction the Pass is currently on. Now it segfaults opt before I can even get a dump() on it. Does anyone see what I am doing wrong? BasicBlock *bb = i->getParent(); Instruction *j = bb->end(); BasicBlock *bb_after = i->getParent()->splitBasicBlock(&*i); bb->getTer...

...l#iterating-over-the-instruction-in-a-function <http://llvm.org/docs/ProgrammersManual.html#iterating-over-the-instruction-in-a-function> > - > Sandeep > > I have following lines in my code, where I need to iterate over the instructions in the function (not BB): > > for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I){ > Instruction *Inst = I; > > Instruction *Inst = &*I; > if (Inst -> getOpcode() == Instruction::GetElementPtr){ > Value* AddrPointer = Inst->getIperand(0); > .... > > if (cast<Operator&gt...

Hi. Thanks. I changed the code but the problem exists. This is my new code which is again very simple: ... bool runOnFunction(Function &F) override { vector<Instruction *> dels; dels.clear(); for (inst_iterator It = inst_begin(&F), Ie = inst_end(&F); It != Ie;) { Instruction *I = &*(It++); if (auto* op = dyn_cast<BinaryOperator>(I)) { IRBuilder<NoFolder> builder(op); Value* lhs = op->getOperand(0); Value* rhs = op->getOperand(1); Value* mul = builder.CreateMul(lhs, rhs); f...