[llvm] r190717 - Adds support for Atom Silvermont (SLM) - -march=slm

[Andrew Trick]

On Sep 20, 2013, at 5:59 AM, Hal Finkel <hfinkel at anl.gov> wrote:

>> For SLM, you may not need the PostRA scheduler at all. I expect the
>> MachineScheduler to be a better fit. You can currently enable the
>> MachineScheduler and it will use your existing (old-style)
>> itineraries (X86SubTarget::enableMachineScheduler() { if (Atom)
>> return true; }). But we really don't want to support that. The
>> proper thing to do for SLM is define an out-of-order machine model.
>> See the SandyBridge/Haswell model.
>> 
>> For original Atom, you might still want a PostRA scheduler. Running
>> the new MachineScheduler a second time as a replacement postRA
>> scheduler is something I intended to do, but haven't had a client.
>> You could enable MachineScheduler and benchmark to determine if
>> PostRA sched is still really needed (-disable-post-ra). If you do
>> still need it, then I’d like to try replacing it with a second
>> MachineScheduler run. We do want to kill off the current PostRA
>> scheduler. It is a maintenance burden that doesn't serve a purpose
>> for targets that have migrated to MachineScheduler.
> 
> Andy,
> 
> I'd certainly like to try this :) -- Post-RA scheduling still gives me ~10-15% speedup on the PPC A2 (just because of the relatively long pipeline, adjusting after the spill code is inserted is quite beneficial).

Ok. I'll see if I can enable a postRA MachineScheduler under a flag and have you run an experiment. If all goes well, we should be able to retire the old postRA scheduler.

One thing you might want to try is disabling the CriticalAntiDepBreaker to see how important it is. Supporting it complicates things.

> Also, regarding the new machine model, can it handle instructions with more than one output where the different outputs have different latencies? My pre-increment loads have this property.

Yes, the new machine model is really just a list of SchedReadWrite entries, one for each operand. Operands that define a register are required to have an SchedWrite entry. SchedRead entries are optional. If an operand is both a def and use, it takes two entries. The order between a read and write entry does not matter.

There are three ways to map these to an instruction:

(1) The proper way (see X86SchedSandyBridge.td)

def WriteA : SchedWrite;
def WriteB : SchedWrite;

def PPCInstXYZ : SomeFormat<...>, Sched<[WriteA, WriteB]>;

let SchedModel = PPCA2Model in {
def ProcUnitA : ProcResource<1>;
def ProcUnitB : ProcResource<1>;

def : WriteRes<WriteA, [ProcUnitA]>;
def : WriteRes<WriteB, [ProcUnitB]>;
}

(2) The Itinerary class adapter (See ARMScheduleA9.td), for targets where the instruction definitions have itinierary classes, but are too convoluted to retrofit with SchedReadWrite lists.

let SchedModel = PPCA2Model in {
def ProcUnitA : ProcResource<1>;
def ProcUnitB : ProcResource<1>;

def A2WriteA : SchedWriteRes<[ProcUnitA]>;
def A2WriteB : SchedWriteRes<[ProcUnitB]>;

def : ItinRW<[A2WriteA, A2WriteB], [ItinX, ItinY, ItinZ]>;
}

(3) The opcode match (See ARMScheduleSwift.td), for targets where the instruction definitions are too convoluted and we either don't have or don't want to continue using itinerary classes.

let SchedModel = PPCA2Model in {
def ProcUnitA : ProcResource<1>;
def ProcUnitB : ProcResource<1>;

def A2WriteA : SchedWriteRes<[ProcUnitA]>;
def A2WriteB : SchedWriteRes<[ProcUnitB]>;
def : InstRW<[A2WriteA, A2WriteB],
            (instregex "PPCIntX", "PPCInstY", "PPCInstZ")>
}

(Yes, the opcode match is verified).

It's ok to use both (1) and (3) in the same subtarget. The idea is that (1) covers the common cases, while (3) lets a subtarget handle a few peculiar cases without complicating the target instruction classes.

If you migrate an in-order itinerary to the new model, please let me know. There's a small addition that I should make to the generic scheduler that you're using to enforce the strict pipeline hazards with the new model, but I'd like someone to test it when I commit.

-Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130922/c2e85ee0/attachment.html>