<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Nov 30, 2011, at 9:11 AM, Sergei Larin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><blockquote type="cite">This is not really so bad, because you can revert to "source order"<br></blockquote><blockquote type="cite">scheduling, -pre-RA-sched=source, and you don't need to implement many<br></blockquote><blockquote type="cite">target hooks. It burns compile time for no good reason, but you can<br></blockquote><blockquote type="cite">probably live with it. Then you're free to implement your own MI-level<br></blockquote><blockquote type="cite">scheduler.<br></blockquote>[Larin, Sergei]<span class="Apple-converted-space"> </span><br> I am not 100% sure about this statement, but as I get closer to<br>re-implementing my scheduler I might grasp a better picture.<br></div></span></blockquote><div><br></div><div>One thing that would be nice to have ASAP is a SelectionDAG serialization pass that satisfies dependencies and physical register interferences, while preserving IR instruction whenever possible. This should be totally separate from from the SelectionDAG scheduler. It should not work on SUnits.</div><div><br></div><div>I realize this is quite disjoint from the work needed to port a new target. I'm just pointing out that it would be a welcome feature.</div><div><br></div><div>If we had that pass, I could tell you that it would be fairly straightforward to reenable the top-down SD scheduler. At this point, since you'd rather scheduler MI's anyway, you may choose to focus on that strategy instead.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><blockquote type="cite">The next step in making it easier to maintain an llvm scheduler for<br></blockquote><blockquote type="cite">"interesting" targets is to build an MI-level scheduling framework and<br></blockquote><blockquote type="cite">move at least one of the primary targets to this framework so it's well<br></blockquote><blockquote type="cite">supported. This would separate the nasty issues of serializing the<br></blockquote><blockquote type="cite">selection DAG from the challenge of microarchitecture-level scheduling,<br></blockquote><blockquote type="cite">and provide a suitable place to inject your own scheduling algorithm.<br></blockquote><blockquote type="cite">It's easier to implement a scheduler when starting from a valid<br></blockquote><blockquote type="cite">instruction sequence where all dependencies are resolved and no<br></blockquote><blockquote type="cite">register interferences exit.<br></blockquote><br><br>[Larin, Sergei]<span class="Apple-converted-space"> </span><br> Agree, and my whole point is that it needs to be done with preceding<br>public discussion, and not de-facto with code drops.<br></div></span></blockquote><div><br></div>It will be an incremental process. I'm not going to design a complete scheduling framework for all microarchitectures "on paper" before making any changes. Design decisions will be deferred as late as they can be without holding up progress. You'll know when they're being made and have the opportunity to influence them. In fact, any new design will be strongly influenced by the scheduler work that you and others have done recently.</div><div><br></div><div>I think you're reacting to the recent dropping of preRA top-down scheduling without public discussion. As you know it was not part of a planned strategy, and not a desirable outcome for anyone. The fact is that we couldn't wait to fix an existing design flaw in DAG serialization. The bottom-up scheduler has the ability to overcome this problem, but implementing a fix that doesn't require running the bottom-up scheduler requires significant work. The right thing to do is to implement SD serialization pass I mentioned above. That solution would be preferable to everyone, but someone needs make the investment.</div><div><br></div><div>Of course, anyone is welcome to fix the existing top-down scheduler as well. It requires implementing the inverse of the bottom-up scheduler's physical register tracking, see LiveRegDefs, plus some really hairy logic for resolving interferences that the SelectionDAG builder has created. </div><div><br></div><div>FWIW, we're not going to run into this issue with the MI scheduling framework that I'm referring to because no part of it will be imposed on any targets.</div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><blockquote type="cite">To answer your question, there's no clear way to describe the current<br></blockquote><blockquote type="cite">overall scheduling strategy. For now, you'll need to ask porting<br></blockquote><blockquote type="cite">questions on llvm-dev. Maybe someone who's faced a similar problem will<br></blockquote><blockquote type="cite">have a good suggestion. We do want to improve that situation and we<br></blockquote><blockquote type="cite">intend to do that by first providing a new scheduler framework. When we<br></blockquote><blockquote type="cite">get to that point, I'll be sure that the new direction can work for you<br></blockquote><br>[Larin, Sergei]<span class="Apple-converted-space"> </span><br>Any clue on time frame?</div></span></blockquote></div><br><div>2012 :)</div><div><br></div><div>-Andy</div></body></html>