<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Apr 6, 2018, at 12:35 AM, Pedro Lopes <<a href="mailto:pedro.fraiao@gmail.com" class="">pedro.fraiao@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">Hello Andy,<br class=""><br class=""></div>I want to use the existing scheduling models to estimate performance on a subtarget. For that, I am looking at the new llvm-mca tool where they only use SchedReadWrite and state that not supporting Instruction Itineraries is a limitation. <br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">llvm-mca tool won't be able to use the new machine model as intended until some of the TargetInstrInfo hooks are moved to the MC layer. That shouldn't be too difficult to do for someone who cares about ARM. Until that's done, the machine model is effectively limited in the same way that itineraries were always limited.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I have also read that the Instruction Itineraries allow to model certain things which cannot be represented in the SchedReadWrite however, I am still trying to find out what and I cannot find any information on this subject.<br class=""><br class="">I was under the impression that, in some cases, Instruction Itineraries could provide me with better static performance estimations. From what you tell me, maybe not? Are Instruction Itineraries somewhat legacy?<br class=""><br class=""></div>- Tiago<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">The intention was that itineraries are completely legacy, but there isn't much incentive to migrate targets that already used them. I don't think they make any sense for out-of-order targets.</div><div class=""><br class=""></div><div class="">For in-order targets, they currently can provide more precision. Itineraries model the resources used at each cycle of instruction execution.</div><div class=""><br class=""></div><div class="">Say InstructionA uses resource X for 2 cycles, then resource Y for 1 cycle (delayed by 2 cycles after instruction issue).</div><div class="">While InstructionB uses resource Y for 2 cycles the first cycle after issue.</div><div class=""><br class=""></div><div class="">Cycle0 IssueA</div><div class="">Cycle1 X IssueB</div><div class="">Cycle2 X Y</div><div class="">Cycle3 Y Y <========= conflict</div><div class=""><br class=""></div><div class="">The new machine model will not report this as a conflict. Itineraries will report the conflict because it always uses a scoreboard even when it isn't needed. </div><div class=""><br class=""></div><div class="">A subtarget scheduling strategy can usually be augmented with logic to handle these special cases. But that defeats the llvm-mca goal of having a complete, self-contained machine model. The new machine model could be extended to model these cases simply by introducing an optional delay cycles attribute for each resource used. I would prefer to see that addition rather than continuing to support LLVM multiple machine models indefinitely.</div><div class=""><br class=""></div><div class="">-Andy</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">2018-04-06 8:34 GMT+02:00 Andrew Trick <span dir="ltr" class=""><<a href="mailto:atrick@apple.com" target="_blank" class="">atrick@apple.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
<br class="">
> On Mar 26, 2018, at 5:18 AM, Pedro Lopes via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
><br class="">
> Hi,<br class="">
><br class="">
> From what I can understand from analyzing several *.td files, there are two ways of specifying scheduling information for a specific target, either using SchedWriteRes and InstrItinClass/Data.<br class="">
><br class="">
> Specifically looking at ARMScheduleA9.td, I can find both representations and a comment (in the beggining of the file):<br class="">
><br class="">
> // This section contains legacy support for itineraries. This is<br class="">
> // required until SD and PostRA schedulers are replaced by MachineScheduler.<br class="">
><br class="">
> This poses several question as to:<br class="">
> 1) which representation gives the better cost estimation?<br class="">
> 2) AFAIK, MachineScheduler can also take advantage from InstrItineraries with the ScoreboardHazardRecognizer for better cost estimation and scheduling.<br class="">
<br class="">
</span>As the comment indicates, this was done for legacy reasons, to allow targets that already defined itineraries to migrate away from SelectionDAG scheduling, without defining a new machine model. What makes you think it was done "for better cost estimation and scheduling”?<br class="">
<span class=""><br class="">
> What is the reasoning for having scheduling information distributed in two distinct representations? Is it the lack of micro-architectural details or was it a design decision?<br class="">
<br class="">
</span>Itineraries classes already existed for ARM, but provided no way to express microarchitectural details, like some vector operations and dependencies on immediate values. (This was compensated for by totally out-of-band logic in the backend to completely override scheduling decisions. That logic is both difficult to maintain, and incompatible with the goal of defining a self-contained machine model.) It also made simple concepts like register bypass very difficult to express and poorly communicated the machine model. The implementation of itineraries (ScoreboardHazardChecker) also needlessly wastes compile time for all but a rare class of VLIW cpus.<br class="">
<span class=""><br class="">
> Another question is if one could opt, which representation should me used to represent scheduling information for new targets?<br class="">
<br class="">
</span>I can’t imagine why someone want to use itineraries for a new target. Maybe you have a reason?<br class="">
<br class="">
-Andy<br class="">
<br class="">
> Best Regards,<br class="">
> Tiago<br class="">
> ______________________________<wbr class="">_________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
<br class="">
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></body></html>