[LLVMdev] Scheduler Roadmap

[dag at cray.com]

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