search for: enablemachineschedul

...(Eric said on IRC that sounded probably a reasonable thing to do but I should ask Andrew first; so cc'd.) I'd propose to do it in a few steps: Step 1: Switch defaults, and all in-tree targets away from selectiondag schedulers and to the machine scheduler. That is, 3 changes: a) Change enableMachineScheduler() -> true by default, and remove target overrides. That would change the behavior of the following in-tree targets (resulting in enabling the new scheduler, and implicitly forcing their ScheduleDAG scheduler to Sched::Source): - ARM (only for some CPUs; others are already using it) - BPF - (H...

I'm briefly enabling the MachineScheduler pass for x86 tonight to collect information on any failures that may show up. To properly enable the new scheduler, this hook is implemented in X86Subtarget: bool enableMachineScheduler() const LLVM_OVERRIDE { return true; } The MachineScheduler pass itself can be enabled/disabled with -enable-misched=true/false. But most of the codegen changes result rather from moving to source-order SD scheduling and subsequent register coalescing decisions. This makes it extremely challengi...

...g 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? Thanks, -Dilan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/a...

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

...AM, Andrew Trick <atrick at apple.com> wrote: > I'm briefly enabling the MachineScheduler pass for x86 tonight to collect > information on any failures that may show up. > > To properly enable the new scheduler, this hook is implemented in > X86Subtarget: > > bool enableMachineScheduler() const LLVM_OVERRIDE { return true; } > > The MachineScheduler pass itself can be enabled/disabled with > -enable-misched=true/false. But most of the codegen changes result rather > from moving to source-order SD scheduling and subsequent register > coalescing decisions. This make...

...3 at 2:41 AM, Andrew Trick <atrick at apple.com> wrote: > I'm briefly enabling the MachineScheduler pass for x86 tonight to collect information on any failures that may show up. > > To properly enable the new scheduler, this hook is implemented in X86Subtarget: > > bool enableMachineScheduler() const LLVM_OVERRIDE { return true; } > > The MachineScheduler pass itself can be enabled/disabled with -enable-misched=true/false. But most of the codegen changes result rather from moving to source-order SD scheduling and subsequent register coalescing decisions. This makes it extremely...

In order for our instruction itineraries to be considered by the instruction scheduler we seem to have to pass -enable-misched to llvm: clang -O3 -mllvm -enable-misched -c some.c ..... If -enable-misched isn't included there it doesn't seem to take our instruction itineraries into account. What's the best way to make '-enable-misched' the default? Phil -------------- next

Hi, I have read the steps of code generation from here: The LLVM Target-Independent Code Generator — LLVM 3.8 documentation |   | |   | |   |   |   |   |   | | The LLVM Target-Independent Code Generator — LLVM 3...Instruction Selection Instruction Selection is the process of translating LLVM code presented to thecode generator into target-specific machine instructions. | | | | View on llvm.org

...ost-RA, right? It's currently only setup to run pre-RA. I'd like to set it up for post-RA also. I don't expect that to be much work. Backends can configure MI scheduler differently depending on how much control they want. The easiest thing to do is define bool <My>SubTargetInfo::enableMachineScheduler() const { return true; } Sorry, did you mention which target you're developing? > >> On Tue, Sep 24, 2013 at 4:07 PM, Andrew Trick <atrick at apple.com> wrote: >> >> On Sep 21, 2013, at 8:02 PM, Liu Xin <navy.xliu at gmail.com> wrote: >> >> &g...

...uding as much analysis as you can. Try to read the -debug-only=misched output. For SLM, you may not need the PostRA scheduler at all. I expect the MachineScheduler to be a better fit. You can currently enable the MachineScheduler and it will use your existing (old-style) itineraries (X86SubTarget::enableMachineScheduler() { if (Atom) return true; }). But we really don't want to support that. The proper thing to do for SLM is define an out-of-order machine model. See the SandyBridge/Haswell model. For original Atom, you might still want a PostRA scheduler. Running the new MachineScheduler a second time as a...

On Wed, Sep 25, 2013 at 1:15 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 24, 2013, at 7:59 PM, Liu Xin <navy.xliu at gmail.com> wrote: > > Hi, Andrew, > > Thank you for answering my question. > > What's the status of misched? is it experimental? I found it is disabled > by default for all architectures(3.4svn). I also don't understand

On 09/05/2013 18:25, Andrew Trick wrote: > > On May 9, 2013, at 4:02 AM, Fraser Cormack <fraser at codeplay.com > <mailto:fraser at codeplay.com>> wrote: > >> I have an instruction that takes no operands, and produces two >> results, in two consecutive cycles. >> >> I tried both of the following to my Schedule.td file: >> >>

...may only occur zero or one times! > specmake: *** [lbm.o] Error 1 > > What does this message mean? > Is this a bug or we are doing something wrong? I’m not sure why the driver is telling you this. Maybe someone familiar with dragonegg can help? You can always rebuild llvm with the enableMachineScheduler() hook implemented. http://article.gmane.org/gmane.comp.compilers.llvm.devel/63242/match=machinescheduler Then -enable-misched=true/false simply toggles MI Sched without changing anything else. > How can we test the MI scheduler by itself? > Is it interesting to test 3.3 or there are int...

Thank you for the answers! We are currently trying to test the MI scheduler. We are using LLVM 3.3 with Dragon Egg 3.3 on an x86-64 machine. So far, we have run one SPEC CPU2006 test with the MI scheduler enabled using the option -fplugin-arg-dragonegg-llvm-option='-enable-misched:true' with -O3. This enables the machine scheduler in addition to the SD scheduler. We have verified this by

...const; >> - >> + >> /// This function returns true if the target has sincos() routine in its >> /// compiler runtime or math libraries. >> bool hasSinCos() const; >> >> + /// Enable the MachineScheduler pass for all X86 subtargets. >> + bool enableMachineScheduler() const LLVM_OVERRIDE { return true; } >> + >> /// enablePostRAScheduler - run for Atom optimization. >> bool enablePostRAScheduler(CodeGenOpt::Level OptLevel, >> TargetSubtargetInfo::AntiDepBreakMode& Mode, >> >> Modified:...