search for: mibundleoperand

...ay all be true. However I'd like to point out that this is the status quo! finalizeBundle() will give you the BUNDLE instruction in the header and it is used by everyone using bundles: ARM, and AMDGPU target and the DFAPacketizer (which is used by Hexagon). Not using BUNDLE and correctly using MIBundleOperands at the right places in the register allocator is not where the code is today! I believe that we are far enough away from it that we should rather fix the status quo first to avoid all the confusion and then move forward to the header-less scheme in a targetted change. That is why I added the last...

...true. However I'd like to point out that this is the status quo! finalizeBundle() will give you the BUNDLE instruction in the header and it is used by everyone using bundles: ARM, and AMDGPU target and the DFAPacketizer (which is used by Hexagon). > > Not using BUNDLE and correctly using MIBundleOperands at the right places in the register allocator is not where the code is today! I believe that we are far enough away from it that we should rather fix the status quo first to avoid all the confusion and then move forward to the header-less scheme in a targetted change. That is why I added the last...

...ingle instruction. - There is (Const)MIOperands which appears to be equivalent to MachineInstr::iterator. I think we do not need a 2nd iterator and should get rid of this one (the only real reason to use it today is analyze{Virt|Phys}Reg() but that can be changed). - There is (Const)MIBundleOperands which iterates all machine operands of all instructions inside a bundle. The last one appears to be necessary in a world without the initial BUNDLE instruction repeating all the operands inside the bundle. In a setting where finalization happens as a separate pass at the end of register alloc...

...gt; - There is (Const)MIOperands which appears to be equivalent to > MachineInstr::iterator. I think we do not need a 2nd iterator and should get > rid of this one (the only real reason to use it today is > analyze{Virt|Phys}Reg() but that can be changed). > - There is (Const)MIBundleOperands which iterates all machine operands of all > instructions inside a bundle. A pass needs to know whether it’s cares about bundles or instructions. I don’t understand how adding an extra BUNDLE instruction does anything to solve this problem or make the MIR more robust. A pass that cares ab...

...that are of interest to us. While we can't upstream that code at the moment, we would really like to retain that form of use. > However given that delaying finalization to a pass appears broken/unused it > seems we could just as well use MachineInstr::iterator instead and remove > MIBundleOperands. Any objections? No. > == Moving to a scheme without repeating the operands in the bundle header == > > I've heard some comments that the long term plan was to move to a scheme where > the operands inside the bundle are not repeated in a bundle header and instead > everyone u...

...to us. While we can't upstream that code at the moment, we would really like to retain that form of use. > > >> However given that delaying finalization to a pass appears broken/unused it >> seems we could just as well use MachineInstr::iterator instead and remove >> MIBundleOperands. Any objections? > > No. > > >> == Moving to a scheme without repeating the operands in the bundle header == >> >> I've heard some comments that the long term plan was to move to a scheme where >> the operands inside the bundle are not repeated in a bund...

Hi Quentin, On 08/19/14 18:58, Quentin Colombet wrote: [...] > It seems that you will have to debug further the *** Bad machine code: Instruction loads from dead spill slot *** before we can be of any help. Yes, I've done some more digging. Sorry for the long mail... I get: Inline spilling aN40_0_7:%vreg1954 [5000r,5056r:0)[5056r,5348r:1) 0 at 5000r 1 at 5056r At this point I have

On Thu, Mar 29, 2012 at 03:51:10PM -0700, Andrew Trick wrote: > > On Mar 29, 2012, at 1:18 PM, Tom Stellard <thomas.stellard at amd.com> wrote: > > > On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: > >> Tom, > >> > >> I do not have your call stack, but packetizer calls > >> ScheduleDAGInstrs::buildSchedGraph to create