[llvm-commits] Target independent VLIW Packetizer

[Andrew Trick]

On Feb 13, 2012, at 2:18 PM, Sundeep <sundeepk at codeaurora.org> wrote:

> Hi Andy,
> 
> I have re-written the VLIW packetizer to accommodate your comments. Please
> find attached the updated patch.

Thanks Sundeep. Committed in r150607.

This patch does not include a client for the framework. I know that's coming next, so at that time please make sure you add test cases in test/Codegen/Hexagon to exercise the functionality added by this patch.

-Andy

> 
> -----Original Message-----
> From: Andrew Trick [mailto:atrick at apple.com] 
> Sent: Monday, February 06, 2012 8:16 PM
> To: Sundeep
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [llvm-commits] Target independent VLIW Packetizer
> 
> On Feb 6, 2012, at 12:06 AM, Sundeep <sundeepk at codeaurora.org> wrote:
>> I have been working on a target independent VLIW packetizer in LLVM. On
> VLIW
>> machines, an instruction packet represents a group of instructions which
> can
>> be executed in parallel. The compiler is responsible for identifying
>> independent machine instructions and grouping those together into packets.
>> The VLIW packetizer in LLVM is implemented as follows:
>> 
>> Implementation Details:
>> 
>> 1. The VLIW packetizer is implemented after all target specific passes are
>> run. This ensures that all pseudo instructions and spill code is
> enumerated
>> before packetization.
>> 
>> 2. The VLIW packetizer extends "ScheduleDAGInstrs" class. The Packetizer
>> uses "BuildSchedGraph" API to build dependence graph. The dependence graph
>> along with deterministic finite automaton (DFA) is used to group
> independent
>> instructions into packets.
>> 
>> 3. The instruction packets are finalized using "finalizeBundle" API. This
>> API inserts BUNDLE instructions and updates each packet instruction with
>> "insideBundle" bit.
>> 
>> 4. The Hexagon backend assembly printer is updated to handle BUNDLE
>> instruction and print packet semantics correctly. Other VLIW targets will
>> also have to update the assembly printer.
>> 
>> The VLIW packetizer roughly implements the following algorithm:
>> 
>> 1 Instantiate DFA resource tracker
>> 2 For all basic blocks (BB) in Machine Function
>> 3 do
>> 4   reset DFA
>> 5   CurrentPacket = {}
>> 6   For all machine instructions (I) in BB
>> 7   do
>> 8     avail = DFA.IsAvailable(I)
>> 9     if (avail == true) {
>> 10       For all machine instructions (Ip) in CurrentPacket
>> 11       do
>> 12         if (DependenceGraph.HasDependence(I, Ip)) {
>> 13           if (Target.CanPruneDependence(I, Ip)) {
>> 14             // End current packet
>> 15             finalizeBundle
>> 16             reset DFA
>> 17             reset CurrentPacket
>> 18           }
>> 19         }
>> 20       done
>> 21     }
>> 22     else {
>> 23       // End current packet
>> 24       finalizeBundle
>> 25       reset DFA
>> 26       reset CurrentPacket
>> 27     }
>> 28
>> 29     // Add I to CurrentPacket
>> 30     CurrentPacket.Add(I)
>> 31   done
>> 32 done
>> 
>> I have already verified that it builds and runs regression test suites
> clean
>> on x86. I attaching the initial patch for review and comments.
> 
> It's nice that you're generalizing the implementation so that it can be
> extended later and serve as a starting point for similar targets. I
> understand you've put a lot of work into that aspect. However, it's also
> important to keep different features of the code generator self contained.
> For example, we should only add hooks to common target headers when they're
> generally applicable, and not specific to VLIW support. It's also important
> to have a consistent scheduling/bundling strategy in the target independent
> code. Eventually, Hexagon will have to move to the new scheudling/bundling
> framework. Until then, the inconsistent bits (i.e. packetizing late) need to
> be confined to the Hexagon target.
> 
> Let me set a few specific goals for this patch:
> 
> 1. Don't touch TargetInstrInfo.h. Only the scheduler or packetizer itself
> should include ScheduleDAG.h. If we need to later, we can make the
> packetizer extensible by providing hook within the packetizer itself. Other
> targets can implement the packetizer interface to exploit those hooks.
> 
> 2. Don't touch LLVMTargetMachine.cpp. We have a preEmit hook already that
> will work for you. For now, you can keep your command line options
> target-local. Later we can share the option across multiple targets of it
> makes sense. TargetPassConfig will handle that. It's not something you need
> to worry about now.
> 
> 3. Don't add any new target-independent passes. It's good to provide stand
> alone utilties that can be used by multiple targets, such as DFAPacketizer
> and VLIWScheduler. However, I don't see much value in providing a driver
> loop that can be shared across targets. Targets provide their own
> scheduling/packetizing pass and share various scheduling utilties bottom-up.
> In particular, a target can extend ScheduleDAGInstrs or DFAPacketizer within
> it own pass. If we see that multiple targets really do need a pass that runs
> at the same time with identical drivers, then we can consider declaring it a
> "target-independent" pass at that time. I realize there's existing code that
> doesn't necessarily follow this strategy. We're working on cleaning it up,
> so it's particularly important not exacerbate the problem at this time.
> 
> Here's my suggestion for now. Any code that should be shared by multiple
> targets that both use DFAPacketizer can go in DFAPacketizer.(h|cpp). For
> example, you can put the VLIWPacketizerList subclass of ScheduleDAGInstrs
> there. I don't see anything in VLIWPacketizerList that's inconstitent with
> the general MachineInstrBundle design. You can then create a new
> HexagonVLIWPacketizer pass within your target and add it during preEmit.
> 
> -Andy
> <vliw-packetizer-patch.txt>