<div dir="ltr"><div>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)<br><br></div>Phil<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 6, 2016 at 3:10 PM, Ehsan Amiri <span dir="ltr"><<a href="mailto:ehsanamiri@gmail.com" target="_blank">ehsanamiri@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Phil<br><br>There are some comments in "include/llvm/Target/TargetItinerary.td" where class InstrItinData is defined.<br><br> 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.<br><br>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.<br><br></div>Hope this helps<br></div>Ehsan<br><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Jun 6, 2016 at 2:37 PM, Phil Tomson via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>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:<br><br>  InstrItinData< II_LOAD1,     [InstrStage<150, [AGU]>]>,<br><br></div>However, I see that there is another field which I haven't specified where operand latencies are specified.  Here's an example from <br><div>ARMScheduleA8.td:<br><br>  InstrItinData<IIC_iALUi ,[InstrStage<1, [A8_Pipe0, A8_Pipe1]>], [2, 2]>,<br><br></div><div>Now I'm wondering if Instead of what I had above, I should instead have specified:<br><br>  InstrItinData< II_LOAD1,     [InstrStage<150, [AGU]>],[150,1,1]>,<br><br></div><div>?<br><br></div><div>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)?<br><br><br></div><div>To clarify, for values of  'A' and 'B' below:<br><br>  InstrItinData< II_LOAD1,     [InstrStage<A, [AGU]>], [B,1,1]>,<br></div><div>  <br></div><div>...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])<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div><div>Phil<br></div></font></span></div>
<br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>