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

[Hal Finkel]

----- 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 3:18:18 PM
> Subject: Re: [llvm-commits] [llvm] r157977 - in /llvm/trunk: include/llvm/CodeGen/ScheduleHazardRecognizer.h
> lib/CodeGen/ScoreboardHazardRecognizer.cpp
> 
> 
> 
> 
> On Dec 3, 2013, at 12:19 PM, 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: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.
> 
> 
> 
> I didn’t realize you were inserting nops to avoid hazards. That’s odd
> for an OOO core.

Yea ;)

> If that’s important, I could see why you want a
> second postRA pass.

Amusingly enough, PPC is currently the only in-tree user of NoopHazard, and not for the embedded cores, but for the ooo cores.

> I recently took a look at adding in-order resources to the
> out-of-order machine scheduler (new scheduling model/no
> itinieraries). I have limited ability/time to test it though beyond
> some quick evaluation on cortex-a9. I can checkin the feature in
> prototype form if you want to experiment and potentially enable it
> for your target.

Yes, please do. I'll play with it.

Thanks again,
Hal

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

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