[PATCH] Two additional hazard recognizer functions

[Hal Finkel]

----- Original Message -----
> From: "Andrew Trick" <atrick at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm commits" <llvm-commits at cs.uiuc.edu>
> Sent: Wednesday, December 4, 2013 6:03:30 PM
> Subject: Re: [PATCH] Two additional hazard recognizer functions
> 
> 
> On Dec 4, 2013, at 3:19 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> > Andy, et al.,
> > 
> > I'd like to add the following two additional interfaces to the
> > hazard recognizer interface. These are optional (in the sense that
> > the default implementations preserve the current behavior), and
> > used by the post-RA scheduler. I need this functionality in order
> > to improve dispatch-group formation on the POWER7 and related
> > cores. Dispatch groups are an odd construct: sometimes we need to
> > insert nops to force a new one to start (for performance reasons),
> > and some instructions need to appear in certain positions within a
> > group, but the groups are not fundamentally cycle based (they can
> > contain instructions with data dependencies with non-trivial
> > latencies).
> > 
> >  /// PreEmitNoops - This callback is invoked prior to emitting an
> >  instruction.
> >  /// It should return the number of noops to emit prior to the
> >  provided
> >  /// instruction.
> >  /// Note: This is only used during PostRA scheduling. EmitNoop is
> >  not called
> >  /// for these noops.
> >  virtual unsigned PreEmitNoops(SUnit *) {
> >    return 0;
> >  }
> > 
> >  /// ShouldPreferAnother - This callback may be invoked if
> >  getHazardType
> >  /// returns NoHazard. If, even though there is no hazard, it would
> >  be better to
> >  /// schedule another available instruction, this callback should
> >  return true.
> >  virtual bool ShouldPreferAnother(SUnit *) {
> >    return false;
> >  }
> > 
> > Motivation:
> > 
> > This first function is used to force the post-RA scheduler to
> > insert nops to force a new dispatch group to begin. We already
> > have a NoopHazard, and this is also still needed. However,
> > NoopHazard only causes a nop to be inserted if there are no other
> > available instructions, and so is not always sufficient. The
> > number of nops to insert depends on state that only the hazard
> > recognizer has, so a general callback is necessary.
> > 
> > The second function is used to avoid scheduling instructions that
> > would start a new dispatch group when others are available that
> > could be part of the current dispatch group. In this case, we
> > don't want to issue nops, because the non-preferred instruction
> > will implicitly start a new dispatch group regardless.
> > 
> > My impression is that, in the long run, we'd like to transition
> > away from itineraries and explicit hazard regcognizers, and I'd
> > like to do that for PowerPC as well. In the mean time, the
> > improvements based on these new interfaces are substantial, and
> > I'd like to commit them to establish a better baseline for future
> > work.
> > 
> > The attached patch adds these functions, and updated the post-RA
> > scheduler to use them. Please review.
> 
> Hi Hal,
> 
> This makes the HazardRecognizer API and PostRA scheduler more
> confusing, but I'm ok with it because I don't think it's worth
> investing in a redesign of that API.

r197084. Thanks!

 -Hal

> 
> Regarding future work... The new machine model should be sufficient
> for expressing your BeginGroup/EndGroup constraints. Hopefully you
> can then do away with HazardRecognizer. Custom scheduling code will
> be needed to insert nops, in addition to a bit more work handling
> dispatch group constraints.
> 
> I'm adding some basic support to GenericScheduler strategy now for
> things like dispatch groups that you can use as an example, but at
> the level that you're tuning you probably want to implement your own
> strategy. If in the end you can get by with adding some hooks to
> GenericScheduler, that's great, but it's good to have a place for
> target-specific experimentation.
> 
> -Andy
> 
> > 
> > Thanks again,
> > Hal
> > 
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> > <hazard-funcs.patch>
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory