<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Book Antiqua";
panose-1:2 4 6 2 5 3 5 3 3 4;}
@font-face
{font-family:Menlo;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Book Antiqua","serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-IE link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Thanks Andrew, that information is a great help. I think I will rewrite our old mechanism to use the method you describe, as we do not currently have a Schedule.td implementation.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal> MartinO<o:p></o:p></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-family:"Book Antiqua","serif"'><o:p> </o:p></span></a></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Andrew Trick [mailto:atrick@apple.com] <br><b>Sent:</b> 30 April 2013 03:21<br><b>To:</b> Martin.ORiordan@movidius.com<br><b>Cc:</b> llvmdev@cs.uiuc.edu; Dev<br><b>Subject:</b> Re: [LLVMdev] Instruction Scheduling - migration from v3.1 to v3.2<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On Apr 26, 2013, at 3:53 AM, Martin J. O'Riordan <<a href="mailto:Martin.ORiordan@movidius.com">Martin.ORiordan@movidius.com</a>> wrote:<o:p></o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>I am migrating the llvm/clang derived compiler for our processor from the<br>v3.1 to v3.2 codebase. This has mostly gone well except that instruction<br>latency scheduling is no longer happening.<br><br>The people who implemented this previously sub-classed 'ScheduleDAGInstrs'<br>and implemented the virtual methods 'computeLatency' and<br>'computeOperandLatency'. However, these methods have been removed from<br>'ScheduleDAG' and 'ScheduleDAGInstrs' so are no longer invoked on our<br>implementation. Instead, the correct approach seems to implement a<br>sub-class of 'TargetSchedModel'.<br><br>When I had a look at how other targets dealt with this transition I found<br>that none of them had implemented the latency scheduler the way we had, so I<br>couldn't just mimic a strategy used by other targets moving from v3.1 to<br>v3.2. Unfortunately the people who implemented the existing solution are no<br>longer with the organization so I am trying to determine how to fix this<br>without their experience.<br><br>Is there any preferred or recommended approach for rewriting our existing<br>implementation to fit the 'TargetSchedModel' mechanism?<o:p></o:p></p></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Hi Martin,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Yes, TargetSchedModel is the machine-instr scheduler's interface to the machine model. It is not extensible. Instead, it checks the current subtarget configuration, and either directly queries latency tables, or calls hooks.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Three possible configurations are:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>(1) No per-opcode tables<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In this case, only one helper is used:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'>unsigned TargetInstrInfo::defaultDefLatency(const MCSchedModel *SchedModel,</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'> const MachineInstr *DefMI) const;</span><o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This is currently non-virtual because it is designed to directly query the fields in the SchedMachineModel tablegen class using another hook to select high latency ops:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>virtual bool isHighLatencyDef(int opc) const;<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Instructions that are not high latency default to one cycle.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Example:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>def GenericModel : SchedMachineModel {<o:p></o:p></p></div><div><p class=MsoNormal> let LoadLatency = 4;<o:p></o:p></p></div><div><p class=MsoNormal> let HighLatency = 10;<o:p></o:p></p></div><div><p class=MsoNormal>}<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If it really helps, you could redeclare defaultDefLatency as a virtual hook and override it.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>(2) The "old" style of pipeline itineraries.<o:p></o:p></p></div><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This is closest to the old behavior. If an itinerary is defined, you get to override two hooks:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'>virtual int TargetInstrInfo::getOperandLatency(const InstrItineraryData *ItinData,</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'> const MachineInstr *DefMI, unsigned DefIdx,</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'> const MachineInstr *UseMI,</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'> unsigned UseIdx) const;</span><o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'>virtual unsigned TargetInstrInfo::getInstrLatency(const InstrItineraryData *ItinData,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'> const MachineInstr *MI,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'> unsigned *PredCost = 0) const;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'> <o:p></o:p></span></p></div></div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'>Example:</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'>def CortexA8Model : SchedMachineModel {</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'> ...</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'> let Itineraries = CortexA8Itineraries;</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Menlo","serif"'>}</span><o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If you don't actually have any itineraries defined in you target's Schedule.td files, you need to define some dummy itinerary with at least one entry. Something like this may work (I haven't tried it).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>def IIC_Default : InstrItinClass;<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>def MyItineraries : ProcessorItineraries<[<o:p></o:p></p></div><div><div><p class=MsoNormal> InstrItinData<IIC_Default, [], []><o:p></o:p></p></div></div><div><p class=MsoNormal>]>;<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>3) The new style of machine model.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Here, you don't use any hooks above the machine model. Instead you define all possible instruction latencies and resources in your .td. For a particular opcode, the model allows selecting the set of resources based on hooks. But all the resources are defined in one place.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-Andy<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>