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

Ehsan Amiri via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 7 20:57:13 PDT 2016

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

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

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

More information about the llvm-dev mailing list