<div dir="ltr">I didn't check 3.6. But in trunk the code to add post-ra scheduler to the pipeline is in TargetPassConfig::addMachinePasses
and is guarded. I copy the related piece of code below. What you have
done, does not turn on post-ra scheduler if it is not enabled. <br><br> // Second pass scheduler.<br> // Let Target optionally insert this pass by itself at some other<br> // point.<br> if (getOptLevel() != CodeGenOpt::None &&<br> !TM->targetSchedulesPostRAScheduling()) {<br> if (MISchedPostRA)<br> addPass(&PostMachineSchedulerID);<br> else<br> addPass(&PostRASchedulerID);</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 8, 2016 at 6:13 PM, Phil Tomson <span dir="ltr"><<a href="mailto:phil.a.tomson@gmail.com" target="_blank">phil.a.tomson@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><div><div>I did some looking around and found this in Passes.cpp:<br>// Temporary option to allow experimenting with MachineScheduler as a post-RA<br>// scheduler. Targets can "properly" enable this with<br>// substitutePass(&PostRASchedulerID, &PostMachineSchedulerID); Ideally it<br>// wouldn't be part of the standard pass pipeline, and the target would just add<br>// a PostRA scheduling pass wherever it wants.<br>static cl::opt<bool> MISchedPostRA("misched-postra", cl::Hidden,<br> cl::desc("Run MachineScheduler post regalloc (independent of preRA sched)"));<br><br></div>So I added this to our target's passConfig subclass:<br>class XSTGPassConfig : public TargetPassConfig {<br>public:<br> XSTGPassConfig(XSTGTargetMachine *TM, PassManagerBase &PM) :<br> TargetPassConfig(TM, PM) {<br> if (TM->getOptLevel() != CodeGenOpt::None)<br> substitutePass(&PostRASchedulerID, &PostMachineSchedulerID);<br> }<br><br><br></div>Then built and ran clang on some code. I had added some couts to the getInstrLatency to display the UseInstr. This is an example of what I see on the output:<br><br>>>> DefInstr: %vreg34<def> = LOADI32_RI %vreg3, 268; mem:LD4[%3](tbaa=<0x75a64d8>) R32C:%vreg34 GPRC:%vreg3 dbg:pipeline_routing_be.c:223:3 @[ pipeline_routing_be.c:1120:1 @[ pipeline_routing_be.c:1120:1 ] ]<br> Latency: 142 for: DefIdx= 0 UseIdx= 1<br> UseInstr: %vreg34<def> = LOADI32_RI %vreg3, 268; mem:LD4[%3](tbaa=<0x75a64d8>) R32C:%vreg34 GPRC:%vreg3 dbg:pipeline_routing_be.c:223:3 @[ pipeline_routing_be.c:1120:1 @[ pipeline_routing_be.c:1120:1 ] ]<br>%vreg35<def> = CVT_U32_TO_U64 %vreg34; GPRC:%vreg35 R32C:%vreg34 dbg:pipeline_routing_be.c:223:3 @[ pipeline_routing_be.c:1120:1 @[ pipeline_routing_be.c:1120:1 ] ]<br><br></div>...since I see vreg's mentioned there, I'm assuming this didn't run postRA as I would have expected.<br><br></div><div>(Our code is based on LLVM 3.6 if that's relevant)<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div>Phil<br><div><div><div><br><div><br></div></div></div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 7, 2016 at 8:57 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">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.<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 7, 2016 at 10:02 PM, Phil Tomson <span dir="ltr"><<a href="mailto:phil.a.tomson@gmail.com" target="_blank">phil.a.tomson@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>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)<span><font color="#888888"><br><br></font></span></div><span><font color="#888888">Phil<br></font></span></div><div><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>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><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>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>