Hi everyone, As I've mentioned before we are doing some work on the LLVM scheduler to improve it. Specifically, we are working to get loads and stores to move past each other when possible. When I asked about enhancing scheduler heuristics a month or so ago, I got a response about a MachineInstr scheduler and that that was the way of the LLVM future. Is that so? Is the ScheduleDAG going away? We found a thread started by Hal late last year with a patch from him to do exactly what we are trying to do - free up load/store motion. The discussion didn't really seem to come to a resolution and the patch doesn't appear in trunk. So we are in a quandry. Do we continue our ScheduleDAG enhancements or do we wait for a MachineInstr scheduler? Will we have to throw away work on ScheduleDAG schedulers? Is there a roadmap for the scheduler? When should we expect a MachineInstr scheduler to be usable? Can it be backported to 3.1? In general, it would be very helpful for folks to post about major architectural changes like this before work begins so the rest of us can plan our work. After all, we are likely to run into the same problems that need solutions. As it is, it gets pretty frustrating to do a bunch of work in the current release only to have to throw it away because someone else did something different. Thanks for any insight you can provide! -Dave
On May 8, 2012, at 3:02 PM, dag at cray.com wrote:> Hi everyone, > > As I've mentioned before we are doing some work on the LLVM scheduler to > improve it. Specifically, we are working to get loads and stores to > move past each other when possible. > > When I asked about enhancing scheduler heuristics a month or so ago, I > got a response about a MachineInstr scheduler and that that was the way > of the LLVM future. Is that so? Is the ScheduleDAG going away?You sent a lengthy RFC on Apr 20 that demonstrated you aren't following developments on trunk. That's perfectly fine, but if you want to use the new scheduler before it is mature, you'll need to follow trunk.> We found a thread started by Hal late last year with a patch from him to > do exactly what we are trying to do - free up load/store motion. The > discussion didn't really seem to come to a resolution and the patch > doesn't appear in trunk.Feel free to use the patch and send your thanks to Hal. It doesn't serve any purpose to mainline a partial solution only to replace it before it can ever be enabled by default, which would require a major performance investigation and introduces a huge risk (AliasAnalysis in CodeGen has not be well tested).> So we are in a quandry. Do we continue our ScheduleDAG enhancements or > do we wait for a MachineInstr scheduler? Will we have to throw away > work on ScheduleDAG schedulers?If you're basing development on anything other than today's trunk, then please continue working on the SelectionDag scheduler. Either way, if the scheduler means that much to you, you'll be developing your own target-specific algorithm. You can do that and be fairly decoupled from target independent changes. Either way, you won't need to throw much away. Target-specific heuristics should be easy to transfer to an MI ScheduleDag from an SD ScheduleDAG. ScheduleDAG doesn't change.> Is there a roadmap for the scheduler? When should we expect a > MachineInstr scheduler to be usable? Can it be backported to 3.1?Only use MachineInstr scheduler now if it solves a pressing problem for you. If you need it in 3.1, then develop your own MachineInstr scheduler using the trunk implementation as a helpful reference. If you're developing based on 3.1, don't expect to upstream changes.> In general, it would be very helpful for folks to post about major > architectural changes like this before work begins so the rest of us can > plan our work. After all, we are likely to run into the same problems > that need solutions. As it is, it gets pretty frustrating to do a bunch > of work in the current release only to have to throw it away because > someone else did something different.There's a difference between having an intention to replace the scheduler (for over a year now) and planning the work. The actual planning coincided nicely with your RFC, providing a good opportunity to air it on llvm-dev. -Andy
Andrew Trick <atrick at apple.com> writes:>> When I asked about enhancing scheduler heuristics a month or so ago, I >> got a response about a MachineInstr scheduler and that that was the way >> of the LLVM future. Is that so? Is the ScheduleDAG going away? > > You sent a lengthy RFC on Apr 20 that demonstrated you aren't > following developments on trunk. That's perfectly fine, but if you > want to use the new scheduler before it is mature, you'll need to > follow trunk.Ok, but that doesn't answer the question. Is SchedulerDAG going away? If so, what's the timeframe for that? 3.2?> Feel free to use the patch and send your thanks to Hal. It doesn't > serve any purpose to mainline a partial solution only to replace it > before it can ever be enabled by default, which would require a major > performance investigation and introduces a huge risk (AliasAnalysis in > CodeGen has not be well tested).Er, but as I understand it the MachineInstr scheduler will also use alias analysis.>> So we are in a quandry. Do we continue our ScheduleDAG enhancements or >> do we wait for a MachineInstr scheduler? Will we have to throw away >> work on ScheduleDAG schedulers? > > If you're basing development on anything other than today's trunk, > then please continue working on the SelectionDag scheduler.But is that going to be throw away work? That's what we need to understand.> Either way, you won't need to throw much away. Target-specific > heuristics should be easy to transfer to an MI ScheduleDag from an SD > ScheduleDAG. ScheduleDAG doesn't change.Ok, if that's the case it will help. But we also need the flexibility provided by Hal's patch. I see that there is some work in that area in the MachineInstr scheduler. A timeline would be help as to when you expect this all to be ready.>> Is there a roadmap for the scheduler? When should we expect a >> MachineInstr scheduler to be usable? Can it be backported to 3.1? > > Only use MachineInstr scheduler now if it solves a pressing problem > for you. If you need it in 3.1, then develop your own MachineInstr > scheduler using the trunk implementation as a helpful reference. > > If you're developing based on 3.1, don't expect to upstream changes.Again, this doesn't answer the questions: - What's the expected release time for the new schedueler? 3.2? - How difficult do you expect a backport to 3.1 to be? We have to work from 3.1. Trunk is too buggy.>> In general, it would be very helpful for folks to post about major >> architectural changes like this before work begins so the rest of us can >> plan our work. After all, we are likely to run into the same problems >> that need solutions. As it is, it gets pretty frustrating to do a bunch >> of work in the current release only to have to throw it away because >> someone else did something different. > > There's a difference between having an intention to replace the > scheduler (for over a year now) and planning the work.Ok, but I don't recall any post about replacing the scheduler. If there was I missed it. That's easy to do on a list with hundreds of messages a day. It would be helpful to have a roadmap page on the LLVM web site to call attention to decisions like this. Such a page could be updated as timelines become firmer.> The actual planning coincided nicely with your RFC, providing a good > opportunity to air it on llvm-dev.I'm not sure what you mean by "planning." Do you mean design work? I think that's quite different from a roadmap with timelines. It's really the former that us non-Apple people need to have to effectively plan our work. The last thing we want to do is duplicate what's already planned to happen. -Dave