[llvm-dev] [RFC][Scheduling] Insert NOPs &&dual issue MIs based on the new MIScheduler

[Tony Jiang via llvm-dev]

Thank you so much Lorenzo, your detailed explanation is very helpful!
Really appreciate it.

Regards,

Yanjun

On Tue, 24 Mar 2020 at 03:56, Lorenzo Casalino via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Yanjun,
>
> > *First*, I thought I could rely on the HazardRecoginer to help me decide
> > when I should insert the NOPs. But we
> > want to use the new MachineSchedModel instead of the legacy Itinerary
> based
> > model. That means we
> > won't define Itinerary model in our backend. Does that mean I cannot use
> > the HazardRecoginzer llvm
> > frame code to help me decide when to insert NOPs? i.e: I need people to
> > help me confirm: whether it
> > is possible to use the LLVM HazardRecoginzer to help deciding when to
> > insert NOPs without defining
> > Itinerary info?
>
> I'm assuming you're referring to the ScoreBoard-based implementation of the
> recognizer (which is the only recognizer implementation available in the
> official trunck of LLVM).
>
> The brief answer is (as far as I know): no, you cannot use the
> ScoreBoard-based
> HazardRecognizer without an Itinerary-based scheduling model.
>
> However, note that the HazardRecognizer
> (include/llvm/HazardRecognizer.h) provides
> only an API, which is agnostic on what sched model is employed; but it
> happens that the backend, up to know, is populated only with recognizers
> based
> on itineraries.
>
> > Hexagon does define *Itinerary *in their
> > MachineSchedModel. This confuses me,
> > does this mean the new MachineSchedModel can work together with the old
> > Itinerary model?
>
> Yes, the new MachineScheduler is able to manage scheduling driven both by
> Itinerary-basedmodel and Per-Operand model. Indeed, when itineraries are
> provided, the (Post)GenericScheduler strategy is initialized with a
> Scoreboard-based HazardRecognizer, skipping any internal scheduling
> tracking.
>
> > Is that the
> > best  way to do scheduling modeling? I was assuming the community now
> > recommend people to use the
> > new MIScheduler + new MachineScheModel for new target development.
> I think that the assumption is correct. Indeed, for instance, recently
> added
> in-order targets (e.g., ARM R52 and ARM M4) employ solely a Per-Operand
> model.
> > And
> > there is also a stand-alone
> > postRA hazard recognizer which runs the hazard recoginzer and emits noops
> > when necessary. It gives targets
> >  a way to run the hazard recognizer without running one of the
> schedulers.
> > Should I explore that one instead?
> Actually, this pass creates a HazardRecognizer via:
>
> (1) "CreateTargetPostRAHazardRecognizer(const MachineFunction &)"
>
> which istarget-dependent.
>
> For instance, ARM backend does not override (1), thus won't create a
> valid recognizer,
> early exiting the postRA hazard recognizer.
>
> As said before, the HazardRecognizer is merely an interface abstracting
> on the specific
> scheduling model provided: if you want to use an hazard recognizer not
> based on itineraries,
> you have to specialize such interface.
>
> > *Second*, about dual issue. How does MIScheduler handle dual issue vs
> > single issue? The only thing that I found
> > was *IssueWidth*，which should be set to 2 if dual issue, and 1 if single
> > issue.
>
> The (Post)GenericScheduler strategy tracks 5 main informations:
>
> 1. CurrCycle: the current cycle where the scheduling decision is taken
>
> 2. CurrMOps: number of micro-ops issued in CurrCycle (usually,
> instructions are modeled as
> 1 mops, but is target-dependent).
>
> 3. Reservation of Resource Units: for how many cycles each units is
> unavailable (i.e., already
> processing an instruction).
>
> 4. PendingQueue: the nodes which cannot be issued due to some hazards.
>
> 5. AvailableQueue: the nodes ready to be issued.
>
> The strategy checks if it is possible to issue an instruction, according
> to (2), (3), (4)
> and (5). Concerning the dual-issuing, this is possible only if there's
> an instruction (MI) in (5),
> such that (2) + MOps(MI) <= IssueLimit, and there's a Resource unit
> ready to consume MI.
>
> As long as such conditions are satisfied, dual-issuing is possible.
>
> > what should I do to insert NOPs? I also looked  ARM
> > backend, it doesn't override the
> > insertNoop() function, does that mean ARM hardware can automatically
> stall
> > when NOP is needed?
> I haven't work with the Scoreboard-based hazard recognizer; hence, I cannot
> tell you how noops are handled in such case. However, in the
> MachineScheduler,
> explicit noop insertion is not required, for the scheduler using (1):
> when no instruction is
> issuable, the pipeline is assumed to be stalled, and (1) bumped until
> (5) is filled with
> an instruction, and scheduling resumed.
> > Any comments and suggestions will be greatly appreciated, thanks!
> The scheduling model for the ARM Cortex-R52, an in-order dual issue
> target, provides a really clean
> and complete per-operand model. I'd really suggest you to look at it :).
>
>
> Cheers,
>
> -- Lorenzo
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200324/764a7227/attachment.html>