[LLVMdev] RFC: Machine Instruction Bundle

[Evan Cheng]

On Dec 2, 2011, at 2:44 PM, David A. Greene wrote:

> Evan Cheng <evan.cheng at apple.com> writes:
> 
>> 2. It must be flexible enough to represent more than VLIW bundles. It
>> should be useful to represent arbitrary sequence of instructions that
>> must be scheduled as a unit. e.g. ARM Thumb2 IT block, Intel compare +
>> branch macro-fusion, or random instruction sequences that are
>> currently modeled as pseudo instructions that are expanded late.
> 
> This is really important.  This kind of support could also aid
> scheduling to make sure some later pass doesn't screw up a carefully
> crafted schedule.
> 
>> So the overall flow should look like this:
>> 
>> 1. DAG to MI lowering (no scheduling!)
>> 2. MI optimizations (LICM, CSE, etc.)
>> 3. Register allocation super pass
>>   3a. De-ssa (2-address, phi slim)
>>   3b. Coalescing
>>   3c. Pre-scheduling packetization (optional)
>>   3d. Pre-RA scheduling (or integrated packetization)
>>   3e. Post-scheduling packetization (optional)
>>   3f. Actual register allocation
>>   3g. Packet finalization
>> 4. Post-RA optimizations
>> 5. PEI
>> 6. Re-schedule restores, copies
> 
> This all looks fairly reasonable to me.  I just have one question.  How
> much machine-level information do we have at the point where bundling
> occurs?  For example, can we figure out instruction sizes exactly?  This
> kind of thing is important for certain kinds of scheduling.

That depends on the target.

> 
> If we don't have that information at this point, it might be
> advantageous to delay the final packetization until later, once we're at
> a point where we have all of the useful information we might want.

Targets are allowed to delay packetization to later. The only restriction is packets cannot be finalized under register allocation is done because we do not want to add virtual register defs and uses to bundle instructions.

Evan
> 
>                         -Dave