[PATCH] Two additional hazard recognizer functions

[Sean Silva]

Do we have any links in docs/CompilerWriterInfo.rst that explain this
dispatch-group thing? If not, could you link to an appropriate manual?

-- Sean Silva


On Wed, Dec 4, 2013 at 6: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.
>
> Thanks again,
> Hal
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131205/1d0d9140/attachment.html>