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

[Andrew Trick]

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. 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