[PATCH] Two additional hazard recognizer functions

[Andrew Trick]

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.

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>