[llvm-dev] Instruction Itineraries: question about operand latencies

[Ehsan Amiri via llvm-dev]

There are two scheduling passes. One is before register allocation and the
other one is after register allocation. You probably looked at the print
outs during first (pre-ra) scheduling pass. Start from
TargetPassConfig::addMachinePasses to find more details about code gen
passes.

On Tue, Jun 7, 2016 at 10:02 PM, Phil Tomson <phil.a.tomson at gmail.com>
wrote:

> I overrode getInstrLatency and did some printing to see what is available
> there. It looks like the registers are still virtual at that point when
> getInstrLatency is called - is that correct? (we needed to make some
> decisions based on actual registers that have been assigned since some
> registers are reserved as address space pointers and we could vary the
> latency based on which address space pointer register is being used - but
> it looks like they're virtual there)
>
> Phil
>
> On Mon, Jun 6, 2016 at 3:10 PM, Ehsan Amiri <ehsanamiri at gmail.com> wrote:
>
>> Hi Phil
>>
>> There are some comments in "include/llvm/Target/TargetItinerary.td" where
>> class InstrItinData is defined.
>>
>>  B is the number of cycles after issue where the first operand of the
>> instruction is defined. A is the number of cycles that the instruction will
>> stay in that particular stage in the pipeline. So for simple cases, like
>> your example, one would expect that A and B should have the same value.But
>> there is different API for accessing to A and B.
>>
>> An example of accessing to B in the source code can be found here:
>> PPCInstrInfo::getInstrLatency. You can also look at getStageLatency in
>> include/llvm/MC/MCInstrItineraries.h. From this two you can probably find
>> other relevant places.
>>
>> Hope this helps
>> Ehsan
>>
>>
>> On Mon, Jun 6, 2016 at 2:37 PM, Phil Tomson via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> In our architecture loads from certain memory locations take a long time
>>> to complete (on the order of 150 clock cycles). Since we don't have a way
>>> to tell at compile time if the address being loaded from lies in slow or
>>> fast memory, I've gone ahead and made all of the load numbers high, such as:
>>>
>>>   InstrItinData< II_LOAD1,     [InstrStage<150, [AGU]>]>,
>>>
>>> However, I see that there is another field which I haven't specified
>>> where operand latencies are specified.  Here's an example from
>>> ARMScheduleA8.td:
>>>
>>>   InstrItinData<IIC_iALUi ,[InstrStage<1, [A8_Pipe0, A8_Pipe1]>], [2,
>>> 2]>,
>>>
>>> Now I'm wondering if Instead of what I had above, I should instead have
>>> specified:
>>>
>>>   InstrItinData< II_LOAD1,     [InstrStage<150, [AGU]>],[150,1,1]>,
>>>
>>> ?
>>>
>>> but is that first '150' parameter there redundant? Since it's specified
>>> in the operand latency list ([150,1,1] - the first element of that array
>>> being the latency for the output)?
>>>
>>>
>>> To clarify, for values of  'A' and 'B' below:
>>>
>>>   InstrItinData< II_LOAD1,     [InstrStage<A, [AGU]>], [B,1,1]>,
>>>
>>> ...what is the difference in the meaning for 'A' and 'B'? Are they
>>> essentially the same value since only one functional unit is specified?
>>> ([AGU])
>>>
>>> Phil
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160607/66a98e98/attachment.html>