[LLVMdev] Scheduler Roadmap

[Jim Grosbach]

On May 9, 2012, at 8:34 AM, dag at cray.com wrote:

> 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.

You've stated that trunk is too buggy for you to work from on multiple occasions. Can you elaborate? That doesn't match my experience, as I install a new compiler on my workstation from a trunk build every night and have only had a problem as a result once in the last year or more. It sounds like you've had a much different experience, which is unfortunate, and perhaps indicates a hole in our buildbot and nightly test infrastructure that could be fixed.

-Jim


> 
>>> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev