search for: mop_iterator

...; MIBundleOperands. If we implement this plan we should rather change >> MachineInstr::iterator later instead of being in the 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 b...

...e implement this plan we should rather change >>> MachineInstr::iterator later instead of being in the 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 bu...

...ould suggest to remove > MIBundleOperands. If we implement this plan we should rather change > MachineInstr::iterator later instead of being in the confusin in-between state > that we have today. > > - Matthias I’m not sure what you mean by changing MachineInstr::iterator. You mean mop_iterator? 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 for the bundle operands. -Andy

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