[llvm-dev] Understanding and Cleaning Up Machine Instruction Bundles

[Matthias Braun via llvm-dev]

> On Oct 27, 2016, at 5:23 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 10/27/2016 4:33 PM, Matthias Braun via llvm-dev wrote:
>> 
>> In fact I am not sure why you would even wait with the finalization and do it
>> in a separate pass rather than doing it immediately after forming the bundle.
>> Using the pass today does not even work as the MachineVerifier will reject the
>> intermediate unfinalized state (missing internal read markers). I'd suggest to get
>> rid of the pass and the idea of delegating finalization to an own pass, any objections?
> 
> No objections. Also, the existing finalizeBundle function works on Hexagon mostly by luck. Hexagon's packet semantics is "mostly" parallel. In general all registers are read before any register updates take place. The current function works by scanning the bundle sequentially. That doesn't cause problems for us, mostly because there is nothing that cares enough about the BUNDLE operands.
> 
> Actually, in our local branch we add immediate operands to the BUNDLE instruction to mark certain properties of the bundle as a whole 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 uses an iterator like MIBundleOperands. I could not find any mails
>> documenting this, so it would be nice if some people could chime in here if
>> that was indeed the plan.
> 
> That sounds wrong. To reiterate, a Hexagon's packet is not equivalent to a sequence of individual instructions. Packetization on Hexagon can be considered irreversible. This may not be the case on other architectures.  Iterating over operands within a bundle without additional information seems random at best.
Just to clarify: No matter the proposal/style the whole bundle is considered a single instruction in terms of liveness / identifying a position in the program. We would not make any assumptions about how the bundle is executed/behaves internally.
The iterator over all operands inside the bundle would just as well give you the union of all defs and use operands inside the bundle (ignoring internal read of course) in a similar fashion to the operands you have on the BUNDLE instruction today.

- Matthias