[LLVMdev] Scheduler Roadmap

[Andrew Trick]

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