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, > HalHal, My first answer was off the top of my head, so missed the subtle issue. Just so you know, to answer questions like this I usually need to instrument the code with tracing or step through in the debugger. Even though I've hacked on the code quite a bit, the interaction between the scheduler and target hooks is still not obvious to me from glancing at the code. FWIW, I'm hoping it can be cleaned up gradually, maybe for the next release. The preRA scheduler is bottom-up, for register pressure tracking. The postRA scheduler is top-down, for simpler hazard detection logic. On ARM, the preRA scheduler uses an unspecialized instance of ScoreboardHazardRecognizer. The machine-independent RecedeCycle() logic that operates on the scheduler itinerary is sufficient. The ARM postRA scheduler specializes the HazardRecognizer to handle additional constraints that cannot be expressed in the itinerary. Since this is a top-down scheduler, RecedeCycle() is no applicable. -Andy> > 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 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 derive from >>>> ScoreboardHazardRecognizer at this point? It looks like the custom >>>> bundling logic could be implemented on top of the scoreboard recognizer >>>> (that seems similar to what ARM's recognizer is doing). >>> >>> Also, how does the ARM hazard recognizer get away with not implementing >>> RecedeCycle? >>> >>> Thanks again, >>> Hal > > -- > Hal Finkel > Postdoctoral Appointee > Leadership Computing Facility > Argonne National Laboratory >
On Tue, 2011-11-29 at 11:40 -0800, Andrew Trick wrote:> 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 issue. Just so you know, to answer questions like this I usually need to instrument the code with tracing or step through in the debugger.This was actually the source of my question, it was clear that the ARM RecedeCycle function was not being called, but, running the PPC code in the debugger, it was clear that the PPC's RecedeCycle function was being called. I did not appreciate the preRA vs postRA distinction, so thank you for explaining that. Instead of trying to port the PPC bundling logic for use with the bottom-up scheduler, maybe it would be sufficient for now to use it postRA (which seems like what ARM is doing). -Hal> Even though I've hacked on the code quite a bit, the interaction between the scheduler and target hooks is still not obvious to me from glancing at the code. FWIW, I'm hoping it can be cleaned up gradually, maybe for the next release. > > The preRA scheduler is bottom-up, for register pressure tracking. The postRA scheduler is top-down, for simpler hazard detection logic. > > On ARM, the preRA scheduler uses an unspecialized instance of ScoreboardHazardRecognizer. The machine-independent RecedeCycle() logic that operates on the scheduler itinerary is sufficient. > > The ARM postRA scheduler specializes the HazardRecognizer to handle additional constraints that cannot be expressed in the itinerary. Since this is a top-down scheduler, RecedeCycle() is no applicable. > > -Andy > > > > > 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 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 derive from > >>>> ScoreboardHazardRecognizer at this point? It looks like the custom > >>>> bundling logic could be implemented on top of the scoreboard recognizer > >>>> (that seems similar to what ARM's recognizer is doing). > >>> > >>> Also, how does the ARM hazard recognizer get away with not implementing > >>> RecedeCycle? > >>> > >>> Thanks again, > >>> Hal > > > > -- > > Hal Finkel > > Postdoctoral Appointee > > Leadership Computing Facility > > Argonne National Laboratory > > >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
On Nov 29, 2011, at 7:10 PM, Hal Finkel wrote:>> From the perspective of the hazard recognizer, from what I can tell, the > difference between the top-down and bottom-up modes are: > > In top-down mode, the scheduling proceeds in the forward direction. > AdvanceCycle() may be used, RecedeCycle() is not used. EmitInstruction() > implies a cycle-count increment. In bottom-up mode, scheduling proceeds > in the backwards direction (last instruction first). AdvanceCycle() is > not used, RecedeCycle() is always used to decrement the current cycle > offset (EmitInstruction() does *not* imply a cycle-count decrement). > > Is this right? Have I captured everything?ScoreboardHazardRecognizer::EmitInstruction checks the reservation table where cycle=0 corresponds to the first pipeline stage and cycle=n is the stage the occurs after n cycles in the itinerary. It doesn't care if we're scheduling top-down or bottom-up. For top-down, the reservation table models resources used by previous instructions, and for bottom-up it models the resources of subsequent instructions, but the EmitInstruction logic is the same either way. AdvanceCycle is called by the current top-down scheduler (now postRA only) to shift the reservation table forward in time. The earliest pipeline stage is dropped. RecedeCycle is called by the bottom-up scheduler (preRA) to shift the reservation table backward in time. The latest pipeline stage is dropped. It's easier to think about hazards in a top-down scheduler. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111129/9a00e128/attachment.html>