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

[Gurd, Preston]

Hello Andy,

Why do you say below that there is "no reason to use itineraries for Atom in the first place"?

In the PostRA scheduler, is there any way to represent the "throughput" (the number of cycles which must elapse before an instruction of the same type can start) of an instruction?

Do you expect that the new machine model will produce a better schedule than the current PostRA scheduler?

Is there any documentation about the new machine model?

Preston




-----Original Message-----
From: Andrew Trick [mailto:atrick at apple.com] 
Sent: Monday, September 16, 2013 2:46 AM
To: Hal Finkel
Cc: Gurd, Preston; llvm-commits at cs.uiuc.edu
Subject: Re: [llvm] r190717 - Adds support for Atom Silvermont (SLM) - -march=slm


On Sep 13, 2013, at 1:26 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> 
>> 
>> Just out of curiosity, when you have this:
>> +  InstrItinData<IIC_SHD16_REG_IM, [InstrStage<2, [IEC_RSV0]>] >,
>> 
>> do you intend this to mean that the shift occupied the IEC_RSV0 unit, 
>> and nothing else can use it for 2 cycles? Or you do mean that the 
>> latency is 2 cycles, but you can still issue back-to-back independent 
>> shifts?
>> 
>> -Hal
>> 
>> For the above itinerary, I am trying to represent that this 
>> instruction must use the IEC reservation station 0 and that it will 
>> take two cycles to execute. I would like to also be able to represent 
>> that the throughput of the instruction is 2 cycles, but I do not know 
>> how to do this.
> 
> Okay, that's what I thought. I think you want to say this:
>  InstrItinData<IIC_SHD16_REG_IM, [InstrStage<1, [IEC_RSV0]>], [2, 1, 
> 1] >,
> 
> The implementation is fully pipelined, right? Assuming that it is, you only need to track the first pipeline stage (because there are no hazards later). The numbers at the end say that the output operand will be ready in cycle 2 post-dispatch, and that the input operands are read in the first cycle.
> 
> I've cc'd Andy so that he can correct me if I'm wrong ;)

Right. Although there is no reason to use itineraries for Atom to begin with. I would be very willing to help anyone who wants to rewrite these using the new machine model, but should be done by someone who can adequately test it. We want to drop support for the old itinerary format and postRA scheduler as soon as possible.

To give you an example, the new model would look something like this:

def : WriteRes<WriteShift, [IEC_RSV0]> { let Latency = 2; }

Maybe a new WriteShiftCL type should be added to X86Schedule.td and referenced in X86InstrShiftRotate.td. Then SLM can define it with Latency = 4, and X86SchedSandyBridge.td can have:

def : SchedAlias<WriteShiftCL, WriteShift>;

It's also possible for a subtarget to override specific operations by pattern matching opcodes without complicating the architecture definitions files.


-Andy