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.
llvm-mca tool won’t be able to use the new machine model as intended until some of the TargetInstrInfo hooks are moved to the MC layer. That shouldn’t be too difficult to do for someone who cares about ARM. Until that’s done, the machine model is effectively limited in the same way that itineraries were always limited.
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?
The intention was that itineraries are completely legacy, but there isn’t much incentive to migrate targets that already used them. I don’t think they make any sense for out-of-order targets.
For in-order targets, they currently can provide more precision. Itineraries model the resources used at each cycle of instruction execution.
Say InstructionA uses resource X for 2 cycles, then resource Y for 1 cycle (delayed by 2 cycles after instruction issue).
While InstructionB uses resource Y for 2 cycles the first cycle after issue.
Cycle1 X IssueB
Cycle2 X Y
Cycle3 Y Y <========= conflict
The new machine model will not report this as a conflict. Itineraries will report the conflict because it always uses a scoreboard even when it isn’t needed.
A subtarget scheduling strategy can usually be augmented with logic to handle these special cases. But that defeats the llvm-mca goal of having a complete, self-contained machine model. The new machine model could be extended to model these cases simply by introducing an optional delay cycles attribute for each resource used. I would prefer to see that addition rather than continuing to support LLVM multiple machine models indefinitely.