[llvm-dev] X86 Backend SelectionDAG - Source Scheduling
Matthias Braun via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 31 15:39:01 PDT 2017
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>
More information about the llvm-dev
mailing list