<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:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" 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=utf-8"><meta name=Generator content="Microsoft Word 15 (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:"Book Antiqua";
panose-1:2 4 6 2 5 3 5 3 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Courier New";
mso-fareast-language:EN-US;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Courier New";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:511339102;
mso-list-type:hybrid;
mso-list-template-ids:952387718 403243033 403243033 403243035 403243023 403243033 403243035 403243023 403243033 403243035;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>This thread is of considerable interest to me. Our scheduler was originally coded for LLVM v2.9 using a sub-class of ‘</span><span style='font-size:12.0pt'>ScheduleDAGInstrs</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>’. I have been aware for some time that the use of ‘</span><span style='font-size:12.0pt'>MachineSchedStrategy</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>’ had become the preferred approach, and with LLVM v3.6 there were no longer any other supported targets that used the legacy strategy. It has been on my “to do” wish-list to rewrite this sometime, but this thread indicates that it is no longer something desirable, but something essential.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>I really admire that the LLVM developer community is willing to refactor and replace older approaches to the compiler with newer and better approaches, and this is what lends great strength to the technology.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>But at the moment our target has not yet been upstreamed (that decision has yet to be made) and I have not been able to track the HEAD revision either due to having a tiny team (also on my wish-list). As a result our implementation is diverging from the mainstream with legacy techniques still present. Bit by bit I am trying to “catch up” and bring our target implementation up to date with the current design.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>Have you any recommendations for me for:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoPlainText style='margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><span style='mso-list:Ignore'>a.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>How to still use the legacy scheduler in LLVM v3.7<o:p></o:p></span></p><p class=MsoPlainText style='margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><span style='mso-list:Ignore'>b.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>How to best approach transporting a legacy ‘</span><span style='font-size:12.0pt'>ScheduleDAGInstrs</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>’ based scheduler to the ‘</span><span style='font-size:12.0pt'>MachineSchedStrategy</span><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>’ based approach<o:p></o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>I need to keep the legacy version working for the immediate future, and to give me breathing space to migrate to the preferred implementation.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'>Thanks,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'> MartinO<o:p></o:p></span></p><p class=MsoPlainText><span style='font-size:12.0pt;font-family:"Book Antiqua",serif'><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-US style='mso-fareast-language:EN-IE'>-----Original Message-----<br>From: llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org] On Behalf Of James Y Knight via llvm-dev<br>Sent: 10 September 2015 23:44<br>To: Quentin Colombet <qcolombet@apple.com><br>Cc: llvm-dev@lists.llvm.org<br>Subject: Re: [llvm-dev] Deprecate and remove old SelectionDAG scheduler</span></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>For step 3, I was actually intending to preserve all the existing code which implements the Sched::Source selectiondag scheduler mode (so, yes, it's still technically a "selectiondag scheduler", just a really dumb one, and with no configuration knobs). I'd only propose to remove code which is needed only for the other sdag scheduler modes. I think that actually will remove the majority of the code.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I'd certainly want to avoid needing to write any new code as part of this.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>On Sep 10, 2015, at 6:16 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com"><span style='color:windowtext;text-decoration:none'>qcolombet@apple.com</span></a>> wrote:<o:p></o:p></p><p class=MsoPlainText>> Hi James,<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> From the bird’s-eye view that looks reasonable.<o:p></o:p></p><p class=MsoPlainText>> Though you’ll need a replacement for the SDAG scheduler to emit the basic block.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> Cheers,<o:p></o:p></p><p class=MsoPlainText>> -Quentin<o:p></o:p></p><p class=MsoPlainText>>> On Sep 10, 2015, at 3:06 PM, James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"><span style='color:windowtext;text-decoration:none'>llvm-dev@lists.llvm.org</span></a>> wrote:<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> While looking at why some generated code for SPARC was poor, I ran into the fact that the MachineScheduler is not yet enabled by default -- it's opt in for each target. Having a bunch of deprecatedish code around was a bit confusing for newbie me.<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> So, I suggested on IRC that perhaps it's been long enough by now that any target that hasn't switched over probably isn't actually caring much for the performance of their target. Has the time come to start getting rid of the old SelectionDAG scheduler? I have no pressing *need* to do this, so if the answer is "no", fine. But if it's "yes", I'm willing to do my part for code cleanliness.<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> (Eric said on IRC that sounded probably a reasonable thing to do but I should ask Andrew first; so cc'd.)<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> I'd propose to do it in a few steps:<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> Step 1: Switch defaults, and all in-tree targets away from selectiondag schedulers and to the machine scheduler.<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> That is, 3 changes:<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> a) Change enableMachineScheduler() -> true by default, and remove target overrides.<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> That would change the behavior of the following in-tree targets (resulting in enabling the new scheduler, and implicitly forcing their ScheduleDAG scheduler to Sched::Source):<o:p></o:p></p><p class=MsoPlainText>>> - ARM (only for some CPUs; others are already using it)<o:p></o:p></p><p class=MsoPlainText>>> - BPF<o:p></o:p></p><p class=MsoPlainText>>> - (Hexagon, only with the non-default -disable-hexagon-misched; I'd remove the option)<o:p></o:p></p><p class=MsoPlainText>>> - MSP430<o:p></o:p></p><p class=MsoPlainText>>> - MIPS<o:p></o:p></p><p class=MsoPlainText>>> - NVPTX<o:p></o:p></p><p class=MsoPlainText>>> - PPC (only for some CPUs; others are already using it)<o:p></o:p></p><p class=MsoPlainText>>> - SystemZ<o:p></o:p></p><p class=MsoPlainText>>> - XCore<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> As part of this, I'd fix tests that fail due to instruction re-orderings, but, I *wouldn't* try to do performance testing of any sort.<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> The targets from the above list that still use the old code which surprise me are ARM and PPC. However, both also usually seem to return true from enablePostRAScheduler -- maybe they really just want to avoid doing machine scheduling both pre-RA and post-RA, and the fact that it also causes the old selectiondag scheduler to get used is an unintended consequence? (And thus, would actually want enableMachineScheduler() -> false, but with Sched::Source as the selectiondag scheduler?)<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> b) Change enableMachineSchedDefaultSched() -> true.<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> Only Hexagon sets that to false currently, with a FIXME near it saying it probably shouldn't. But, that is actually irrelevant, normally, since it uses Sched::Source as its scheduler in any case -- unless an option "-enable-hexagon-sdnode-sched" is passed. I'd remove that option too.<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> c) Change the default for SchedPreferenceInfo in TargetLoweringBase.cpp to Sched::Source. If everyone also uses enableMachineScheduler() -> true and enableMachineSchedDefaultSched() -> true, this has no effect of course. But just to be clear what the future is, I'd suggest to change it too. :) <o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> After this step, out-of-tree targets could still have "enableMachineScheduler()" return false, and call "setSchedulingPreference(Sched::ILP)" (or whatever other option), if they want to keep using the old scheduler after this step, until step 3 happens.<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> Step 2: Wait for some time to pass, for people to notice performance regressions, or otherwise complain.<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> Step 3: Delete all the selectiondag scheduling code, the above 3 customization points, and whatever other hooks/apis are dead. Rejoice at the deletion of code!<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> Does the above sound sane (today is the first time I've actually looked at all this code, so if I've misunderstood something, do let me know!) Is it okay to execute step 1?<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> _______________________________________________<o:p></o:p></p><p class=MsoPlainText>>> LLVM Developers mailing list<o:p></o:p></p><p class=MsoPlainText>>> <a href="mailto:llvm-dev@lists.llvm.org"><span style='color:windowtext;text-decoration:none'>llvm-dev@lists.llvm.org</span></a><o:p></o:p></p><p class=MsoPlainText>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"><span style='color:windowtext;text-decoration:none'>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</span></a><o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>_______________________________________________<o:p></o:p></p><p class=MsoPlainText>LLVM Developers mailing list<o:p></o:p></p><p class=MsoPlainText><a href="mailto:llvm-dev@lists.llvm.org"><span style='color:windowtext;text-decoration:none'>llvm-dev@lists.llvm.org</span></a><o:p></o:p></p><p class=MsoPlainText><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"><span style='color:windowtext;text-decoration:none'>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</span></a><o:p></o:p></p></div></body></html>