[llvm-dev] X86 Backend SelectionDAG - Source Scheduling

Matthias Braun via llvm-dev
Mon, 31 Jul 2017 22:39:01 -0000

Yes looking at the MachineScheduler.cpp and the `SchedMachienModel`s in the
targets along with -debug-only=machine-scheduler / -print-machineinstrs  is the
way to understand scheduling.

- Matthias

> On Jul 31, 2017, at 3:36 PM, Dilan Manatunga <manatunga at gmail.com>
wrote:
>
> Thanks that clears things up. So if I want to mess around with how
schedules are generated, looking at the MachineScheduler pass is the best place
now?
>
> -Dilan
>
> On Mon, Jul 31, 2017 at 3:24 PM Matthias Braun <mbraun at apple.com
<mailto:mbraun at apple.com>> wrote:
>
> > On Jul 31, 2017, at 2:51 PM, Dilan Manatunga via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> > Hi,
> >
> > I was looking into how SelectionDAG scheduling is done in LLVM for
different backends, and I noticed that for the X86 backend, even though it sets
scheduling preferences of ILP or RegisterPressure depending on architecture, in
the end, it ends up using source scheduling. I realized this is because it
overrides enableMachineScheduler to return true. Is there any specific reasons
why it was done this way, and also, what happens to be class mainly responsible
for the X86 scheduling then?
>
> The MachineScheduler is consider the standard scheduler and does a better
job at tracking among other things register pressure and machine
state/latencies, features a more modular design etc.
>
> The SelectionDAG schedulers are still here because:
> - We need to bring the selection graph back into a linear order for the MI
representation. While we would like the SelectionDAG scheduler to be as simple
as an RPO walk, it also does:
> - Duplicating/Rematerializing of flag producing nodes in order to avoid
unnecessary spilling/restoring of flag registers (which is an expensive
operation on most architectures).
>
> Scheduling for any other goals in the selection dag scheduler and using
something else than the source/fast scheduler is considered deprecated.
> That said for some targets the machine scheduler tuning efforts were never
finished (or maybe just never verified?) so that they still use the other
selection dag scheduler.
>
> - Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170731/9170c57e/attachment.html>