[LLVMdev] [llvm-commits] Bottom-Up Scheduling?

[Hal Finkel]

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