[llvm-commits] [llvm] r157977 - in /llvm/trunk: include/llvm/CodeGen/ScheduleHazardRecognizer.h lib/CodeGen/ScoreboardHazardRecognizer.cpp

Tue Dec 3 12:19:31 PST 2013

----- 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: Tuesday, December 3, 2013 1:46:30 PM
> Subject: Re: [llvm-commits] [llvm] r157977 - in /llvm/trunk: include/llvm/CodeGen/ScheduleHazardRecognizer.h
> lib/CodeGen/ScoreboardHazardRecognizer.cpp
> 
> 
> 
> 
> On Dec 3, 2013, at 11:31 AM, Hal Finkel < hfinkel at anl.gov > wrote:
> 
> 
> 
> ----- 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: Tuesday, December 3, 2013 1:15:38 PM
> Subject: Re: [llvm-commits] [llvm] r157977 - in /llvm/trunk:
> include/llvm/CodeGen/ScheduleHazardRecognizer.h
> lib/CodeGen/ScoreboardHazardRecognizer.cpp
> 
> 
> 
> 
> On Dec 3, 2013, at 11:05 AM, Hal Finkel < hfinkel at anl.gov > wrote:
> 
> 
> 
> ----- 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: Tuesday, December 3, 2013 12:15:08 PM
> Subject: Re: [llvm-commits] [llvm] r157977 - in /llvm/trunk:
> include/llvm/CodeGen/ScheduleHazardRecognizer.h
> lib/CodeGen/ScoreboardHazardRecognizer.cpp
> 
> 
> On Dec 3, 2013, at 9:19 AM, Hal Finkel < hfinkel at anl.gov > wrote:
> 
> 
> 
> ----- Original Message -----
> 
> 
> From: "Andrew Trick" < atrick at apple.com >
> To: llvm-commits at cs.uiuc.edu
> Sent: Monday, June 4, 2012 10:44:32 PM
> Subject: [llvm-commits] [llvm] r157977 - in /llvm/trunk:
> include/llvm/CodeGen/ScheduleHazardRecognizer.h
> lib/CodeGen/ScoreboardHazardRecognizer.cpp
> 
> Author: atrick
> Date: Mon Jun 4 22:44:32 2012
> New Revision: 157977
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=157977&view=rev
> Log:
> misched: Allow disabling scoreboard hazard checking for subtargets
> with a
> valid itinerary but no pipeline stages.
> 
> An itinerary can contain useful scheduling information without
> specifying pipeline stages for each instruction.
> 
> Modified:
> llvm/trunk/include/llvm/CodeGen/ScheduleHazardRecognizer.h
> llvm/trunk/lib/CodeGen/ScoreboardHazardRecognizer.cpp
> 
> Modified:
> llvm/trunk/include/llvm/CodeGen/ScheduleHazardRecognizer.h
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/ScheduleHazardRecognizer.h?rev=157977&r1=157976&r2=157977&view=diff
> ==============================================================================
> --- llvm/trunk/include/llvm/CodeGen/ScheduleHazardRecognizer.h
> (original)
> +++ llvm/trunk/include/llvm/CodeGen/ScheduleHazardRecognizer.h Mon
> Jun 4 22:44:32 2012
> @@ -46,6 +46,8 @@
> 
> /// atIssueLimit - Return true if no more instructions may be
> issued in this
> /// cycle.
> + ///
> + /// FIXME: remove this once MachineScheduler is the only
> client.
> 
> Does this mean that the MachineScheduler does, or will, do PostRA
> scheduling as well?
> 
> When I implemented MachineScheduler, the plan was that both SD
> scheduler and PostRA scheduler would be eliminated. Then the
> scheduling data structure could be further streamlined for
> simplicity and compile time. I don’t see a fundamental reason the
> machine scheduler can’t run as a PostRA pass, it just needs to be
> setup to do that.
> 
> Do you mean calling substitutePass(&PostRASchedulerID,
> &MachineSchedulerID)? Or some kind of 'setup' within the machine
> scheduler itself?
> 
> 
> 
> I’m pretty sure something will break when you do that. But it should
> just be a matter of disabling certain features when running in
> PostRA mode. e.g. LiveIntervals and RegPressure tracking should be
> disabled.
> 
> Fair enough. We'd also want to run anti-dependency breaking.
> 
> 
> 
> I’m not sure if you’ll want AliasAnalysis.
> 
> I'm also not sure; I'm experimenting with this now for avoiding
> load-after-store hazards.
> 
> 
> 
> 
> 
> It would be nice if we could conditionally enable postRA scheduling
> just for blocks with spill/prolog/epilog code. Maybe we want an
> Analysis pass to remember these blocks.
> 
> Agreed (unless I need a second top-down pass anyway, for dispatch
> group formation on the POWER cores, for example).
> 
> 
> Your commit mentioned that only postRA handled dispatch groups. Do
> you simply mean that it is a top-down scheduling pass?

This is one of the things that I'm working on fixing. It had been the case for some time that we were only doing dispatch-group formation PostRA. I don't remember exactly why now, but it had something the way that the existing hazard recognizer was written.

> 
> 
> The bottom-up pass should also be trying to form dispatch groups. The
> actual groups will differ at execution time because of the partial
> group at the beginning of the block, so the processor may
> opportunistically move some instructions into earlier groups, but
> final throughput should be the same as in the scheduler’s model.

I agree. However, there are two parts to this: First is modeling the dispatch slots as resources (which can certainly be done in either direction). The second is inserting noops where necessary to force a new dispatch groups. I'm not sure that doing that bottom-up makes sense. On the other hand, I think that doing this bottom-up may only be problematic if you need to insert multiple noops (because you don't know how many to insert until you schedule the preceding group), and for all recent POWER cores, there is a special 'group ending' noop, so this may not be an issue.

> In
> fact, I would guess that the processor can dispatch across branches,
> so the scheduler’s groups won’t perfectly reflect reality anyway.

I could be wrong, but I think that, for the purpose of avoiding LS hazards, this is not true (but certainly could effect non-epoch-based hazards [my terminology] like register rename slots).

Thanks again,
Hal

> 
> 
> -Andy
> 
> 
> 
> 
> 
> -Hal
> 
> 
> 
> 
> -Andy
> 
> 
> 
> 
> -Hal
> 
> 
> 
> 
> -Andy
> 
> 
> 
> -Hal
> 
> 
> 
> virtual bool atIssueLimit() const { return false; }
> 
> /// getHazardType - Return the hazard type of emitting this
> node.
> There are
> 
> Modified: llvm/trunk/lib/CodeGen/ScoreboardHazardRecognizer.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/ScoreboardHazardRecognizer.cpp?rev=157977&r1=157976&r2=157977&view=diff
> ==============================================================================
> --- llvm/trunk/lib/CodeGen/ScoreboardHazardRecognizer.cpp
> (original)
> +++ llvm/trunk/lib/CodeGen/ScoreboardHazardRecognizer.cpp Mon Jun
> 4
> 22:44:32 2012
> @@ -39,9 +39,9 @@
> DebugType = ParentDebugType;
> #endif
> 
> - // Determine the maximum depth of any itinerary. This
> determines
> the
> - // depth of the scoreboard. We always make the scoreboard at
> least
> 1
> - // cycle deep to avoid dealing with the boundary condition.
> + // Determine the maximum depth of any itinerary. This
> determines
> the depth of
> + // the scoreboard. We always make the scoreboard at least 1
> cycle
> deep to
> + // avoid dealing with the boundary condition.
> unsigned ScoreboardDepth = 1;
> if (ItinData && !ItinData->isEmpty()) {
> IssueWidth = ItinData->IssueWidth;
> @@ -63,16 +63,22 @@
> // Find the next power-of-2 >= ItinDepth
> while (ItinDepth > ScoreboardDepth) {
> ScoreboardDepth *= 2;
> + // Don't set MaxLookAhead until we find at least one
> nonzero
> stage.
> + // This way, an itinerary with no stages has
> MaxLookAhead==0, which
> + // completely bypasses the scoreboard hazard logic.
> + MaxLookAhead = ScoreboardDepth;
> }
> }
> - MaxLookAhead = ScoreboardDepth;
> }
> 
> ReservedScoreboard.reset(ScoreboardDepth);
> RequiredScoreboard.reset(ScoreboardDepth);
> 
> - DEBUG(dbgs() << "Using scoreboard hazard recognizer: Depth = "
> - << ScoreboardDepth << '\n');
> + if (!MaxLookAhead)
> + DEBUG(dbgs() << "Disabled scoreboard hazard recognizer\n");
> + else
> + DEBUG(dbgs() << "Using scoreboard hazard recognizer: Depth =
> "
> + << ScoreboardDepth << '\n');
> }
> 
> void ScoreboardHazardRecognizer::Reset() {
> 
> 
> _______________________________________________
> 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
> 
> 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 

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