[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: "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?

Thanks again,
Hal

> I think things will also clear up as we add
> more subtargets. The X86 models will be very interesting. I'll also
> be able to add the Swift model once my current scheduler work is
> done. Note that the scheduler I'm designing works best with the new
> machine model, while the VLIW scheduler builds a state machine from
> itineraries. For those of you working on VLIW targets, itineraries
> may still be a good way to go. Once non-VLIW targets are weened off
> itineraries, the VLIW community will be free to simplify itineraries
> in a way that better meets their needs. Or if they find the level of
> detail in the new model is sufficient, they can switch over.
> 
> -Andy
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

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