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

[Andrew Trick]

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.

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