[PATCH] Two additional hazard recognizer functions

[Hal Finkel]

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.

Thanks again,
Hal

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hazard-funcs.patch
Type: text/x-patch
Size: 4851 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131204/957b82d6/attachment.bin>