similar to: [LLVMdev] Bottom-Up Scheduling?

On Oct 25, 2011, at 6:01 PM, Hal Finkel wrote: > Is there documentation somewhere for the bottom-up scheduling? I'm > trying to figure out what changes are necessary in order to support it > in the PPC backend. > > Thanks in advance, > Hal > > On Thu, 2011-10-20 at 10:21 -0700, Evan Cheng wrote: >> >> On Oct 19, 2011, at 7:29 PM, Hal Finkel <hfinkel at

On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > On Oct 25, 2011, at 6:01 PM, Hal Finkel wrote: > > Is there documentation somewhere for the bottom-up scheduling? I'm > > trying to figure out what changes are necessary in order to support it > > in the PPC backend. > > > > Thanks in advance, > > Hal > > > > On Thu, 2011-10-20 at

On Mon, 2011-12-19 at 07:41 -0800, Andrew Trick wrote: > On Dec 19, 2011, at 6:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > > Now, to generate the best PPC schedules, there is one thing you may > >> want to override. The scheduler's priority function has a > >> HasReadyFilter attribute

On Dec 19, 2011, at 3:19 PM, Hal Finkel wrote: > On Mon, 2011-12-19 at 07:41 -0800, Andrew Trick wrote: >> On Dec 19, 2011, at 6:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> >>> On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: >>> Now, to generate the best PPC schedules, there is one thing you may >>>> want to override. The

On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: Now, to generate the best PPC schedules, there is one thing you may > want to override. The scheduler's priority function has a > HasReadyFilter attribute (enum). It can be overriden by specializing > hybrid_ls_rr_sort. Setting this to "true" enables proper ILP > scheduling, and maximizes the instructions that can

On Dec 19, 2011, at 6:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: > On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > Now, to generate the best PPC schedules, there is one thing you may >> want to override. The scheduler's priority function has a >> HasReadyFilter attribute (enum). It can be overriden by specializing >> hybrid_ls_rr_sort. Setting this to

On Tue, 2011-11-22 at 13:27 -0600, Hal Finkel wrote: > On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > > On Oct 25, 2011, at 6:01 PM, Hal Finkel wrote: > > > Is there documentation somewhere for the bottom-up scheduling? I'm > > > trying to figure out what changes are necessary in order to support it > > > in the PPC backend. > > > >

On Mon, 2011-12-19 at 22:14 -0800, Andrew Trick wrote: > On Dec 19, 2011, at 3:19 PM, Hal Finkel wrote: > > > On Mon, 2011-12-19 at 07:41 -0800, Andrew Trick wrote: > >> On Dec 19, 2011, at 6:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> > >>> On Tue, 2011-10-25 at 21:00 -0700, Andrew Trick wrote: > >>> Now, to generate the best

On Dec 20, 2011, at 10:29 AM, Hal Finkel wrote: > On Tue, 2011-12-20 at 10:35 -0600, Hal Finkel wrote: >> On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: >>> >>> On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: >>> >>>> Here's my "thought experiment" (from PR11589): I have a bunch of >>>> load-fadd-store chains to

On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: > > On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > > > Here's my "thought experiment" (from PR11589): I have a bunch of > > load-fadd-store chains to schedule. A store takes two cycles to > > clear > > its last pipeline stage. The fadd takes longer to compute its result > > (say 5

On Tue, 2011-12-20 at 10:35 -0600, Hal Finkel wrote: > On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: > > > > On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > > > > > Here's my "thought experiment" (from PR11589): I have a bunch of > > > load-fadd-store chains to schedule. A store takes two cycles to > > > clear > >

On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > Here's my "thought experiment" (from PR11589): I have a bunch of > load-fadd-store chains to schedule. A store takes two cycles to clear > its last pipeline stage. The fadd takes longer to compute its result > (say 5 cycles), but can sustain a rate of 1 independent add per cycle. > As the scheduling is bottom-up, it

On Nov 29, 2011, at 10:47 AM, Hal Finkel wrote: > Andy, > > I should have been more clear, the ARM implementation has: > void ARMHazardRecognizer::RecedeCycle() { > llvm_unreachable("reverse ARM hazard checking unsupported"); > } > > How does that work? > > Thanks again, > Hal Hal, My first answer was off the top of my head, so missed the subtle

Andy, I should have been more clear, the ARM implementation has: void ARMHazardRecognizer::RecedeCycle() { llvm_unreachable("reverse ARM hazard checking unsupported"); } How does that work? Thanks again, Hal On Tue, 2011-11-29 at 09:47 -0800, Andrew Trick wrote: > ARM can reuse all the default scoreboard hazard recognizer logic such as recede cycle (naturally since its the

On Mon, 2011-11-28 at 15:45 -0800, Andrew Trick wrote: > > On Nov 28, 2011, at 3:35 PM, Hal Finkel wrote: > > > > > > > Is EmitInstruction used in bottom-up scheduling at all? The > > > version in > > > the ARM recognizer seems essential, but in all of the regression > > > tests > > > (and some other .ll files I have lying around),

ARM can reuse all the default scoreboard hazard recognizer logic such as recede cycle (naturally since its the primary client). If you can do the same with PPC that's great. Andy On Nov 29, 2011, at 8:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> Thanks! Since I have to change PPCHazardRecognizer for bottom-up support >> anyway, is there any reason not to have it

On Tue, 2011-11-29 at 08:29 -0600, Hal Finkel wrote: > On Mon, 2011-11-28 at 15:45 -0800, Andrew Trick wrote: > > > > On Nov 28, 2011, at 3:35 PM, Hal Finkel wrote: > > > > > > > > > > Is EmitInstruction used in bottom-up scheduling at all? The > > > > version in > > > > the ARM recognizer seems essential, but in all of the

On Nov 28, 2011, at 3:35 PM, Hal Finkel wrote: >> >> Is EmitInstruction used in bottom-up scheduling at all? The version in >> the ARM recognizer seems essential, but in all of the regression tests >> (and some other .ll files I have lying around), it is never called. It >> seems that only Reset() and getHazardType() are called. Could you please >> explain the

Hi Andrew, What we have is not a patch to any of LLVM's schedulers. We have implemented our own scheduler and integrated it into LLVM 2.9 as yet-another scheduler. Our scheduler uses a combinatorial optimization approach to balance ILP and register pressure. In one experiment, we added more precise latency information for most common x86 instructions to our scheduler and noticed a 10%

On Sep 23, 2011, at 6:16 AM, Ghassan Shobaki wrote: > Hi Andrew, > > What we have is not a patch to any of LLVM's schedulers. We have implemented our own scheduler and integrated it into LLVM 2.9 as yet-another scheduler. Our scheduler uses a combinatorial optimization approach to balance ILP and register pressure. In one experiment, we added more precise latency information for