[LLVMdev] RFC: Machine Instruction Bundle

David A. Greene greened at obbligato.org
Fri Dec 2 14:44:58 PST 2011


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.

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.

                         -Dave



More information about the llvm-dev mailing list