search for: someinstruction

Hi, everytime one has to add instruction at the beginning of a basic block, one has to skip past PHI nodes that are already there. How about adding a new method to BasicBlock, to get that first non-PHI instruction? So, adding an instruction will be as simple as: new SomeInstruction(............., BB->getFirstNonPHI()) Patch attached. Comments? - Volodya -------------- next part -------------- A non-text attachment was scrubbed... Name: BasicBlock.diff Type: text/x-diff Size: 1679 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/2006...

...: > everytime one has to add instruction at the beginning of a basic block, one > has to skip past PHI nodes that are already there. How about adding a new > method to BasicBlock, to get that first non-PHI instruction? So, adding an > instruction will be as simple as: > > new SomeInstruction(............., BB->getFirstNonPHI()) Sure, sounds good. A couple requests: 1. Please add a const version that returns a const Instruction* also. 2. There is no need to check for running off the end of the basic block, you are guaranteed that a block has a terminator, which is not a PHI. -Ch...

...is: IRBuilder<> IB(Context); Vector.push_back(IB.CreateXXX()); Vector.push_back(IB.CreateXXX()); Vector.push_back(IB.CreateXXX()); ... // Other stuff for (SmallVectorImpl<Instruction*>::iterator I = Vector.begin(), E = Vector.end(); I != E; ++I) { SomeBB->getInstList().insert(SomeInstruction, *I); } If I add the instructions like this I get strange results. It's like if llvm gets corrupted or something similar, because in the backend strange things happen, like MCRegisterInfo returning wrong register aliasing information in a random fashion (sometimes happens and sometimes doe...

...ction at the beginning of a basic >> block, one >> has to skip past PHI nodes that are already there. How about adding a new >> method to BasicBlock, to get that first non-PHI instruction? So, >> adding an >> instruction will be as simple as: >> >> new SomeInstruction(............., BB->getFirstNonPHI()) > > 2. There is no need to check for running off the end of the basic block, > you are guaranteed that a block has a terminator, which is not a PHI. Assuming it's a valid BasicBlock. Which, if I understand correctly, isn't always true in mi...

...has to add instruction at the beginning of a basic block, >> one has to skip past PHI nodes that are already there. How about adding a >> new method to BasicBlock, to get that first non-PHI instruction? So, >> adding an instruction will be as simple as: >> >> new SomeInstruction(............., BB->getFirstNonPHI()) > > Sure, sounds good. A couple requests: > > 1. Please add a const version that returns a const Instruction* also. I was considering it, but then decided that given that you can't pass 'const Instruction*' as 'insert before...

...confusin in-between state >> that we have today. >> >> - Matthias > > I’m not sure what you mean by changing MachineInstr::iterator. You mean mop_iterator? Oh sorry, I was talking about mop_iterator indeed. The thing you get when you use `for (MachineOperand &MO : someinstruction.operands()) { ... }` which is the standard for the majority of codegen passes today. > > You can’t replace an instr iterator with a bundle iterator without breaking some basic invariants: > MI == MI->operands_begin()->getParent() > > That’s why passes should explicitly ask f...

...;>> that we have today. >>> >>> - Matthias >> >> I’m not sure what you mean by changing MachineInstr::iterator. You mean mop_iterator? > Oh sorry, I was talking about mop_iterator indeed. The thing you get when you use > `for (MachineOperand &MO : someinstruction.operands()) { ... }` which is the standard for the majority of codegen passes today. > >> >> You can’t replace an instr iterator with a bundle iterator without breaking some basic invariants: >> MI == MI->operands_begin()->getParent() >> >> That’s why passe...

> On Oct 27, 2016, at 2:33 PM, Matthias Braun <mbraun at apple.com> wrote: > > == BUNDLE instruction / operands == > For many backend passes a bundle can appear as a single unit. However one important tool > here is having an iterator over all operands of this unit. > > The original RFC indicates that to achieve this without changing a big number > of passes an

I am using machine instruction bundles [1] before register allocation. This appears not to be too common today and I'd really like some input on the intentions and plans of the current system. And would like some input on clean up proposals. [1] I am currently experimenting to use machine instruction bundles to reliably form macroop fusion opportunities without spills, reloads, splits or