[LLVMdev] Scheduler Roadmap

[dag at cray.com]

Andrew Trick <atrick at apple.com> writes:

>> Ok, but that doesn't answer the question.  Is SchedulerDAG going away?
>> If so, what's the timeframe for that?  3.2?
>
> SchedulerDAG is used for both SD scheduling and MI scheduling. It's not going away.

Oh!  That's good news!

> SD scheduling is not going away in 3.2--it will be the first release with MI scheduling on by default.

Ok, that is helpful.  Thanks!

> If all goes well, I expect SD scheduling to be removed by 3.3. That has not been discussed.

Is there any particular reason to remove it?  Something has to convert
from SDNodes to MachineInstrs so we'll at least need the "original
order" SUnit scheduler, yes?

> Here's a more complete list of the implementation steps, but the real
> effort will be spent in performance analysis required before flipping
> the switch. Don't expect it to be an adequate replacement out-of-box
> for your benchmarks before 3.2.

Understood.

> - AliasAnalysis aware DAG option: In review (Sergei)

This is going to be very important to us.  I believe this accomplishes
the same thing as Hal's patch and work we've done here.  I'm really glad
to see this here!

> If you would simply like improved X86 scheduling without rolling your
> own, then providing feedback and test cases is useful so we can
> incorporate improvements into the standard scheduler while it's being
> developed.

Yep.

>> Er, but as I understand it the MachineInstr scheduler will also use
>> alias analysis.
>
> AliasAnalysis is important. We want it fully supported and enabled by
> default, but that requires effort beyond simply enabling it. Today,
> that effort is in the MI scheduler.

Yes of course.  Does this mean alias analysis in general will be
available at the MachineInstr level?  I've run into a desire for that
multiple times.

> The information I provided above is the best I can do, and as early as
> I could provide this level of detail. If you follow trunk, you can see
> the direction things are heading, but until recently I would not have
> been able to tell you "plans" in the form of dates or release goals.

This is really helpful, thanks!

                                 -Dave