[llvm-commits] [llvm] r165602 - in /llvm/trunk: include/llvm/MC/MCSchedule.h utils/TableGen/SubtargetEmitter.cpp

[Hal Finkel]

----- Original Message -----
> From: "Andrew Trick" <atrick at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvm-commits at cs.uiuc.edu, "Tom Stellard" <tom at stellard.net>
> Sent: Wednesday, October 10, 2012 2:40:58 PM
> Subject: Re: [llvm-commits] [llvm] r165602 - in /llvm/trunk: include/llvm/MC/MCSchedule.h
> utils/TableGen/SubtargetEmitter.cpp
> 
> On Oct 10, 2012, at 12:15 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> > 
> > ----- Original Message -----
> >> From: "Andrew Trick" <atrick at apple.com>
> >> To: "Tom Stellard" <tom at stellard.net>
> >> Cc: llvm-commits at cs.uiuc.edu
> >> Sent: Wednesday, October 10, 2012 12:28:49 PM
> >> Subject: Re: [llvm-commits] [llvm] r165602 - in /llvm/trunk:
> >> include/llvm/MC/MCSchedule.h
> >> utils/TableGen/SubtargetEmitter.cpp
> >> 
> >> On Oct 10, 2012, at 7:02 AM, Tom Stellard <tom at stellard.net>
> >> wrote:
> >> 
> >>> On Wed, Oct 10, 2012 at 05:43:04AM -0000, Andrew Trick wrote:
> >>>> Author: atrick
> >>>> Date: Wed Oct 10 00:43:04 2012
> >>>> New Revision: 165602
> >>>> 
> >>>> URL: http://llvm.org/viewvc/llvm-project?rev=165602&view=rev
> >>>> Log:
> >>>> misched: Generate IsBuffered flag for machine resources.
> >>>> 
> >>>> Modified:
> >>>>   llvm/trunk/include/llvm/MC/MCSchedule.h
> >>>>   llvm/trunk/utils/TableGen/SubtargetEmitter.cpp
> >>>> 
> >>>> Modified: llvm/trunk/include/llvm/MC/MCSchedule.h
> >>> 
> >>> Hi Andrew,
> >>> 
> >>> Would you mind giving a brief overview of what you are working on
> >>> with
> >>> all these MCSchedule changes?  Will these changes require updates
> >>> to
> >>> backends as well?
> >> 
> >> 
> >> Hi Tom,
> >> 
> >> There are two things going on here: development of a new scheduler
> >> and introduction of a new target description for machine models.
> >> My
> >> goal is to stage both in without affecting the behavior of
> >> existing
> >> backends, which is challenging but the only way to proceed. I
> >> can't
> >> guarantee you won't have any merge conflicts--it depends on how
> >> much
> >> of the scheduling framework you use and at what level of API--but
> >> you can let me know and I'll try to help.
> >> 
> >> Work on the new scheduler has been ongoing, but very spotty, for
> >> the
> >> past year. Checking in support for the new machine model has
> >> allowed
> >> me to unblock that work. In the next few weeks I'll be adding
> >> logic
> >> and heuristics to MachineScheduler based on the machine model.
> >> 
> >> The cortex A9 subtarget provides an example of the new machine
> >> model.
> >> It captures the information that the new scheduler needs, does it
> >> concisely, allows the free-form description to match the layout of
> >> whatever microarchitecture spec you have your hands on, and
> >> largely
> >> removes the need for target hooks in the scheduler. I've found
> >> that
> >> the implementation of these hooks is not verified and prone to
> >> silent merge bugs.
> >> 
> >> Unfortunately, the A9 description is designed for incremental
> >> bootstrapping, and not how I would like a machine model to be
> >> designed from scratch. In particular, I don't think it's a good
> >> idea
> >> to continue using itinerary classes. I'm also afraid the A9
> >> description will scare people off because of the seemingly
> >> outrageous handling of load/store multiple instructions. Half of
> >> the
> >> LDM/VLDM junk could be removed by fixing the machine IR to be
> >> consistent. The other half is necessary but better than the
> >> alternative of target hooks and switch statements. At least the
> >> processor's model is defined in one place and not subject to merge
> >> bugs.
> >> 
> >> So, you can see we should have a discussion before anyone wants to
> >> start using this model for their own backend. I'm waiting until
> >> that
> >> happens before getting into a deep discussion because it's
> >> important
> >> discuss concrete issues.
> > 
> > At some point, I'd like to have a discussion on how to apply the
> > new infrastructure to the various PowerPC targets. Are we ready
> > for that now?
> 
> 
> Yes, in the sense that I'm not expecting to add major features
> machine model any time soon, except making it easier to derive one
> processor's model from another. I'm not sure you have an immediate
> need, since you already have an itinerary out-of-tree.  We'll be in
> a better position to measure performance in a few weeks after
> misched is actually using the information. At that point you'll be
> able to toggle between the itinerary and new model.

Alright, sounds good.

At the moment, my primary concern is for the in-tree itineraries (for the A2 specifically). I'd like to be able to take advantage of the new alias-analysis-based dependency breaking (enable-aa-sched-mi) [and stop using my hack to the selection DAG builder], and if I understand things correctly, I need the new infrastructure to do that.

Thanks again,
Hal

> 
> Once you start investigating using TargetSchedule.td to define
> PowerPC subtargets, just send me some examples of the cases you want
> to handle, and I'll be able to suggest alternatives.
> 
> -Andy
> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory