[llvm-commits] FW: Hexagon VLIW instruction scheduler framework patch for review

[Sergei Larin]

Tom, 

  Thank you for your comments. Please see some answers embedded below.

Sergei

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.

> -----Original Message-----
> From: Tom Stellard [mailto:thomas.stellard at amd.com]
> Sent: Tuesday, January 31, 2012 10:09 AM
> To: Sergei Larin
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [llvm-commits] FW: Hexagon VLIW instruction scheduler
> framework patch for review
> 
> On Tue, Jan 31, 2012 at 09:18:05AM -0600, Sergei Larin wrote:
> >
> >   Hello everybody,
> >
> >
> >
> >     Attached is initial patch for a VLIW specific scheduler framework
> that
> > utilizes deterministic finite automaton (DFA) .
> >
> >
> >
> > Several key points:
> >
> > -          The scheduler is largely based on the existing framework,
> but
> > introduces several VLIW specific concepts. It could be classified as
> a top
> > down list scheduler, critical path first, with DFA used for parallel
> > resources modeling. It also models and tracks register pressure in
> the way
> > similar to the current RegPressure scheduler. It employs a slightly
> > different way to compute "cost" function for all SUs in AQ which
> allows for
> > somewhat easier balancing of multiple heuristic inputs. Current
> version does
> > _not_ generates bundles/packets (but models them internally). It
> could be
> > easily modified to do so, and it is our plan to make it a part of
> bundle
> > generation in the near future.
> >
> > -          The scheduler is enabled for the Hexagon backend.
> Comparing to
> > any existing scheduler, for this VLIW target this code produces
> between 1.9%
> > slowdown and 11% speedup on our internal test suite. This test set
> comprised
> > from a variety of real world applications ranging from DSP specific
> > applications to SPEC. Some DSP kernels (when taken out of context)
> enjoy up
> > to 20% speedup when compared to the "default" scheduling mechanism
> > (RegPressure pre-RA + post RA). Main reason for this kind of corner
> case
> > behavior is long chains of independent memory accesses that are
> > conservatively serialized by the default scheduler (and there is no
> HW
> > scheduler to sort it out at the run time).
> >
> > -          This patch is an initial submission with a bare minimum of
> > features, and more heuristics will be added to it later. We prefer to
> submit
> > it in stages to simplify review process and improve SW management.
> >
> > -          Patch also contains minor updates to two Hexagon specific
> tests
> > in order to compensate for new order of instructions generated by the
> > Hexagon backend __with scheduler disabled__.
> >
> > -          SVN revision 149130. LLVM verification test run for x86
> platform
> > detects no additional failures.
> >
> >
> >
> >   Comments and reviews are eagerly anticipated J
> >
> 
> 
> Hi Sergei,
> 
> I'm glad to see a VLIW scheduler proposed for LLVM.  We are working on
> an LLVM backend for our Evergreen / Northern Islands open source
> drivers,
> which are also VLIW.  I'm hoping we can use this in our backend as
> well.
> I just have a few questions and comments.
> 
> When you start doing bundle generation in the scheduler will you be
> using the new MachineInstrBundle?  How are you going to model bundle

[Larin, Sergei]  Yes, definitely. This patch is just the first step. Once
complete, hopefully we will have full blown VLIW centric scheduler. Any
feedback from perspective of your architecture will be very welcomed. The
goal here is not to target single back end, but rather to introduce the best
value for the whole project.

> constraints?  I'm not familiar with the Hexagon architecture, but our
> hardware has several bundle constraints.  For example, some
> instructions
> can only be in a certain slot within the bundle, while other
> instructions
> fill all slots in the bundle.  There is also a limit to the number of
> constant registers (these are in a different register space than the
> GPRs)
> that can be read from within the bundle, among other things.  It would
> be nice to have some way to apply these constraints in the scheduler.

[Larin, Sergei]  Hexagon is very similar in terms of bundle slot
restrictions. We use the DFA state machine (see this thread
http://groups.google.com/group/llvm-commit/browse_thread/thread/d7c0fe14c70c
6be6/e5fe95e2d1feb521?#e5fe95e2d1feb521 for example) which is automatically
generated from your machine description, and statefully encodes (hopefully)
all the above mentioned constraints. If there is some constraint in your
architecture that could not be addressed by the DFA, we could augment it, or
introduce some sort of target specific peephole/constraint checker hook into
the scheduler. Have you looked at current DFA implementation? It has been
around for a couple months now, and if you have questions my colleague could
easily address those. 
> 
> A quick note on the patch, I noticed a few whitespace errors in
> LinkAllCodegenComponents.h, SchedulerRegistry.h, and
> HexagonInstrInfo.cpp



[Larin, Sergei] Thanks... I'll wait for more comments and will address them
all at once :)
> 
> Nice Work!
[Larin, Sergei] Thanks again.
> 
> -Tom Stellard
> >
> >
> > Thanks.
> >
> >
> >
> > Sergei Larin
> >
> >
> >
> > --
> >
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.
> >
> >
> >
> 
> 
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>