[llvm-dev] InstrItin and SchedWriteRes

[Pedro Lopes via llvm-dev]

Hello Andy,

I want to use the existing scheduling models to estimate performance on a
subtarget. For that, I am looking at the new llvm-mca tool where they only
use SchedReadWrite and state that not supporting Instruction Itineraries is
a limitation.

I have also read that the Instruction Itineraries allow to model certain
things which cannot be represented in the SchedReadWrite however, I am
still trying to find out what and I cannot find any information on this
subject.

I was under the impression that, in some cases, Instruction Itineraries
could provide me with better static performance estimations. From what you
tell me, maybe not? Are Instruction Itineraries somewhat legacy?

- Tiago



2018-04-06 8:34 GMT+02:00 Andrew Trick <atrick at apple.com>:

>
>
> > On Mar 26, 2018, at 5:18 AM, Pedro Lopes via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Hi,
> >
> > From what I can understand from analyzing several *.td files, there are
> two ways of specifying scheduling information for a specific target, either
> using SchedWriteRes and InstrItinClass/Data.
> >
> > Specifically looking at ARMScheduleA9.td, I can find both
> representations and a comment (in the beggining of the file):
> >
> > // This section contains legacy support for itineraries. This is
> > // required until SD and PostRA schedulers are replaced by
> MachineScheduler.
> >
> > This poses several question as to:
> > 1) which representation gives the better cost estimation?
> > 2) AFAIK, MachineScheduler can also take advantage from InstrItineraries
> with the ScoreboardHazardRecognizer for better cost estimation and
> scheduling.
>
> As the comment indicates, this was done for legacy reasons, to allow
> targets that already defined itineraries to migrate away from SelectionDAG
> scheduling, without defining a new machine model. What makes you think it
> was done "for better cost estimation and scheduling”?
>
> > What is the reasoning for having scheduling information distributed in
> two distinct representations? Is it the lack of micro-architectural details
> or was it a design decision?
>
> Itineraries classes already existed for ARM, but provided no way to
> express microarchitectural details, like some vector operations and
> dependencies on immediate values. (This was compensated for by totally
> out-of-band logic in the backend to completely override scheduling
> decisions. That logic is both difficult to maintain, and incompatible with
> the goal of defining a self-contained machine model.) It also made simple
> concepts like register bypass very difficult to express and poorly
> communicated the machine model. The implementation of itineraries
> (ScoreboardHazardChecker) also needlessly wastes compile time for all but a
> rare class of VLIW cpus.
>
> > Another question is if one could opt, which representation should me
> used to represent scheduling information for new targets?
>
> I can’t imagine why someone want to use itineraries for a new target.
> Maybe you have a reason?
>
> -Andy
>
> > Best Regards,
> > Tiago
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://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/20180406/39de6f49/attachment.html>