[PATCH] Two additional hazard recognizer functions

Hal Finkel hfinkel at anl.gov
Wed Dec 11 05:12:30 PST 2013


----- Original Message -----
> From: "Sean Silva" <silvas at purdue.edu>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm commits" <llvm-commits at cs.uiuc.edu>
> Sent: Thursday, December 5, 2013 5:36:26 PM
> Subject: Re: [PATCH] Two additional hazard recognizer functions
> 
> 
> Do we have any links in docs/CompilerWriterInfo.rst that explain this
> dispatch-group thing? If not, could you link to an appropriate
> manual?

Hrmm... it would help if IBM would provide stable links for these things...

The PPC 970 users manual discusses this:
https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/DC3D43B729FDAD2C00257419006FB955

Also, the POWER7 paper by Sinharoy, et al., discusses this; unfortunately, the normative download for this is not free:
http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=5730623
(an industrious programmer can likely find a free copy using Google or similar)

Suggestions?

Thanks again,
Hal

> 
> 
> -- 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
> 
> 
> 

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



More information about the llvm-commits mailing list