[llvm-commits] Target independent VLIW Packetizer

[Sundeep]

Hi Andy,

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

Thanks,
Sundeep

-----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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vliw-packetizer-patch.txt
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120213/5e3f2531/attachment.txt>