search for: getiterator

Within a basic block this is just normal iterator usage/manipulation: for (instr : llvm::make_range(FromInstruction.getIterator(), ToInstruction.getIterator())) { ... } Use std::next() on ToInstruction.getIterator() if you want it included. - Matthias > On Apr 9, 2018, at 10:04 AM, Alexandre Isoard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > Is there an iterator to iterate over...

Hello, Is there an iterator to iterate over a "range" of instructions in a Function? "range" meaning from an instruction::iterator up to an other instruction::iterator which either: - point to instructions in the same basic block (the first one first, second one second) - point to instructions in different basic block (the BB of the first dominate the BB of the second, and

...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 therefore safe to compare to an iterator. +1. The convenience of the implicit conversion isn't worthwhile here. While I'm not a huge fan of writing `&*I`, it's at least very obvious that you need to check that I'...

.../llvm/lib/Transforms/InstCombine/InstructionCombining.cpp @@ -3012,7 +3012,7 @@ static bool prepareICWorklistFromFunction(Function &F, const DataLayout &DL, while (EndInst != BB->begin()) { // Delete the next to last instruction. Instruction *Inst = &*--EndInst->getIterator(); - if (!Inst->use_empty()) + if (!Inst->use_empty() && !Inst->getType()->isTokenTy()) Inst->replaceAllUsesWith(UndefValue::get(Inst->getType())); - if (Inst->isEHPad()) { + if (Inst->isEHPad() || Inst->getType()->isTokenTy()) {...

...Combine/InstructionCombining.cpp > @@ -3012,7 +3012,7 @@ static bool prepareICWorklistFromFunction(Function > &F, const DataLayout &DL, > while (EndInst != BB->begin()) { > // Delete the next to last instruction. > Instruction *Inst = &*--EndInst->getIterator(); > - if (!Inst->use_empty()) > + if (!Inst->use_empty() && !Inst->getType()->isTokenTy()) > Inst->replaceAllUsesWith(UndefValue::get(Inst->getType())); > - if (Inst->isEHPad()) { > > + if (Inst->isEHPad() || Inst->g...

...[where both I and new_inst are Instruction*] >> >> In LLVM 3.8 however, the SymbolTableList was created as a wrapper over >> iplist. >> Could anyone please tell me how I can do the same type of insertion in >> LLVM 3.8? >> > > auto InsertPt = I->getIterator(); > BB->getInstList().insert(InsertPt, new_inst); > > Thanks, Daniel! In your example, isn't "insert" inserting "new_inst" *before* instruction "I"? As I would like to insert the "new_inst" instruction after "I", shouldn't...

I think the implicit iterator conversions are much less important now that we have range based for loops, but I still like having them. On Tue, Oct 20, 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

...Combine/InstructionCombining.cpp > @@ -3012,7 +3012,7 @@ static bool prepareICWorklistFromFunction(Function > &F, const DataLayout &DL, > while (EndInst != BB->begin()) { > // Delete the next to last instruction. > Instruction *Inst = &*--EndInst->getIterator(); > - if (!Inst->use_empty()) > + if (!Inst->use_empty() && !Inst->getType()->isTokenTy()) > Inst->replaceAllUsesWith(UndefValue::get(Inst->getType())); > - if (Inst->isEHPad()) { > > + if (Inst->isEHPad() || Inst->g...

...for each_custom(arg, *func, arg_begin, arg_end) 7 arg_list.push_back(&*arg); 8 for each(arg, arg_list){ 9 Argument *arg_dup = new Argument((*arg)->getType(), makeName(*arg, "_dup")); 10 func->getArgumentList().insertAfter((*arg)->getIterator(), arg_dup); 11 } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170324/6648b45b/attachment.html>

Hello, I'm trying to add a new instruction after a given instruction in a basic block. Until LLVM 3.7, I was using the following code: BB->getInstList().insertAfter(I, new_inst); [where both I and new_inst are Instruction*] In LLVM 3.8 however, the SymbolTableList was created as a wrapper over iplist. Could anyone please tell me how I can do the same type of insertion in LLVM 3.8?

...; >>>> In LLVM 3.8 however, the SymbolTableList was created as a wrapper over >>>> iplist. >>>> Could anyone please tell me how I can do the same type of insertion in >>>> LLVM 3.8? >>>> >>> >>> auto InsertPt = I->getIterator(); >>> BB->getInstList().insert(InsertPt, new_inst); >>> >>> >> Thanks, Daniel! >> >> In your example, isn't "insert" inserting "new_inst" *before* instruction >> "I"? >> As I would like to insert the...

...e your out-of-tree call sites. >> Note that these conversions are occasionally latent bugs (that may >> happen to "work" now, but only because of getting lucky with UB; >> follow-ups will change your luck). When they are valid, I suggest using >> `->getIterator()` to go from pointer to iterator, and `&*` to go from >> iterator to pointer. >> >>> >>> Is this change indeed intended as a visible API change to source code generating references to argument list values? If so, can you point me to a description of h...

Hi, I am upgrading my project from 3.7 to 3.8. I find that following code used to compile in 3.7 but doesn't in 3.8 and I can't understand why. llvm::Function *mainFunc = ...; auto argiter = mainFunc->arg_begin(); llvm::Value *arg1 = argiter++; arg1->setName("obj"); But if I change the code to following it compiles: auto argiter = mainFunc->arg_begin(); llvm::Value

...patch downstream while you update your out-of-tree call sites. Note that these conversions are occasionally latent bugs (that may happen to "work" now, but only because of getting lucky with UB; follow-ups will change your luck). When they are valid, I suggest using `->getIterator()` to go from pointer to iterator, and `&*` to go from iterator to pointer. > > Is this change indeed intended as a visible API change to source code generating references to argument list values? If so, can you point me to a description of how I should change our code? S...

...analysis. // In this case not really necessary since the green nodes of the // loop bodies are reused. DependenceAnalysis->transferAnalysis(Red1->getBody(), RedFused->getBody()[0], ClosedExprAnalysis->makeIdentityMapping(Red1->getIterator(), RedFused->getIterator())); DependenceAnalysis->transferAnalysis(Red2->getBody(), RedFused->getBody()[1], ClosedExprAnalysis->makeIdentityMapping(Red2->getIterator(),...

I'm trying to write a tablegen pattern to that matches a sequence of SDNodes and emits again an SDNode and another instruction. The pattern I've written looks like the folowing: def : Pat<(foo (bar GPR:$rs1), simm12:$imm1), (bar (BAZ GPR:$rs1, simm12:$imm1))>; foo and bar are SDNodes, BAZ is an instruction. In particular, bar is defined as follows: def bar :

...sites. >>>> Note that these conversions are occasionally latent bugs (that may >>>> happen to "work" now, but only because of getting lucky with UB; >>>> follow-ups will change your luck). When they are valid, I suggest using >>>> `->getIterator()` to go from pointer to iterator, and `&*` to go from >>>> iterator to pointer. >>>> >>>>> >>>>> Is this change indeed intended as a visible API change to source code generating references to argument list values? If so, can you po...

> On Jun 28, 2017, at 5:10 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh wait, vreg1 is indeed used. > Yeah, having a dead flag here sounds wrong. I mean on the instruction itself. On the bundle, that’s debatable. That would fit the semantic “if no side effect you can kill it” (here there is side effect, we define other vregs). > >> On

Hi Quentin and llvm-dev, I've got a regalloc-related question that you might have an opinion or answer about. In our out-of-tree target we've been doing some bundling before register allocation for quite some time now, and last night a new problem popped up. What the fix should be depends on if this bundle is legal or not: BUNDLE %vreg39<imp-def,dead> *

Thank you for your reply! > Every MachineBasicBlock has a list of successors; you can access it with > the successors() accessor. That's what you should be using for any CFG > analysis. I am aware of these methods of class MachineBasicBlock, which allows one to access a MachineBasicBlock's successors and predecessors in the CFG. But the CFG itself may no longer be valid if a