similar to: How to make -enable-misched the default?

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 Sep 25, 2013, at 11:03 PM, Liu Xin <navy.xliu at gmail.com> wrote: > > > > 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

Hello Andy, Thank you for your offer to work together on implementing the your new scheduler on X86. I can start working on this right away. In case you were unaware, the new Silvermont micro-architecture is only out of order on the integer side. The SSE instructions are still in order, so the current postRA scheduler is very beneficial for code with lots of SSE instructions, such as the ISPC

Hi Phil. You more or less answered your own question, but let me give you some more info. Maybe it is of use. >From what I understand the SchedMachineModel is the future, although it is not as powerful as itineraries at present. The mi-scheduler is mostly developed around out-of-orders cores, I believe (I love to hear arguments on the contrary). Some of the constraints that can be found in

I think those should be considered internal options for (llvm codegen) developers, a normal compiler user should not need to use any of them. Of course you can look around the llvm sourcecode (esp. in lib/CodeGen/MachineScheduler.cpp) and see what cl::opt options are available and how they affect the scheduler operation. In case of the MachineScheduler all settings are the same regardless of the

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 the algorithm. Could you point to me more papers or text materials about your approach? it seems that you want to balance register pressure and ILP in misched. On Tue, Sep 24, 2013 at 4:07 PM,

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 the algorithm. Could you point to me more papers or text materials about your approach? it seems

So if I use the SchedMachineModel method, can I just skip itineraries? Phil On Wed, Apr 20, 2016 at 12:29 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Target does make a difference. VLIW needs more hand-holding. For what you > are describing it should be fairly simple. > > > > Best strategy – see what other targets do. ARM might be a good start for > generic

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

I see that there are several options to influence instruction scheduling, but there doesn't seem to be a lot of information about what they do, for example: -misched-topdown -misched-bottomup The description in MachineScheduler.cpp says: "Force top-down list scheduling" and "Force bottom-up list scheduling" Which isn't too helpful - where might I want to use these?

I overrode getInstrLatency and did some printing to see what is available there. It looks like the registers are still virtual at that point when getInstrLatency is called - is that correct? (we needed to make some decisions based on actual registers that have been assigned since some registers are reserved as address space pointers and we could vary the latency based on which address space

Hi Andy, thanks for your help!! The scheduled code by method A is same as B when using the new machine model. it's make sense, but there is the another problem, the scheduled code is badly. load/store instruction always reuse the same register Source: #define N 2000000 static double b[N], c[N]; void Scale () { double scalar = 3.0; for (int j=0;j<N;j++) b[j] =

On Jun 11, 2012, at 9:30 AM, Hal Finkel <hfinkel at anl.gov> wrote: > I'm considering writing more-detailed itineraries for some PowerPC CPUs > that use the 'traditional' instruction grouping scheme. In essence, > this means that multiple instructions will stall in some pipeline stage > until a complete group is formed, then all will continue. > > I expect to

On Mon, Aug 22, 2016 at 11:40 AM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Aug 22, 2016, at 11:20, Phil Tomson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > We improved our instruction itineraries and now we're seeing our > testcases for fence instructions break. > > > > For example, we have this testcase: > >

On Oct 15, 2013, at 9:28 PM, Zakk <zakk0610 at gmail.com> wrote: > Hi Andy, thanks for your help!! > The scheduled code by method A is same as B when using the new machine model. > it's make sense, but there is the another problem, the scheduled code is badly. > > load/store instruction always reuse the same register I filed PR17593 with this information. However, I

We improved our instruction itineraries and now we're seeing our testcases for fence instructions break. For example, we have this testcase: @write_me = external global i32 @read_me = external global i32 ; Function Attrs: nounwind define i32 @xstg_intrinsic(i32 %foo) #0 { entry: ; CHECK: store r0, r1, 0, 32 ; CHECK-NEXT: fence 2 %foo.addr = alloca i32, align 4 store i32 %foo,

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

I'm considering writing more-detailed itineraries for some PowerPC CPUs that use the 'traditional' instruction grouping scheme. In essence, this means that multiple instructions will stall in some pipeline stage until a complete group is formed, then all will continue. I expect to provide CPU-specific code to help determine when the currently-waiting instructions would form a group.

On Jun 24, 2013, at 2:47 AM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, Jun 24, 2013 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:

While looking at why some generated code for SPARC was poor, I ran into the fact that the MachineScheduler is not yet enabled by default -- it's opt in for each target. Having a bunch of deprecatedish code around was a bit confusing for newbie me. So, I suggested on IRC that perhaps it's been long enough by now that any target that hasn't switched over probably isn't actually