Page MenuHomePhabricator

[AArch64] Basic Sched Model for Cortex-A57

Authored by cestes on Jun 3 2014, 1:41 PM.



Define the numerous SchedWriteRes types specific to Cortex-A57 and
then alias those to the default SchedWrite types. Future work will
more precisely map these specific SchedWriteRes types to instructions
via InstRWs. Additionally basic forwarding and hazards may be modeled.

Diff Detail


Event Timeline

cestes updated this revision to Diff 10060.Jun 3 2014, 1:41 PM
cestes retitled this revision from to [AArch64] Basic Sched Model for Cortex-A57.
cestes updated this object.
cestes edited the test plan for this revision. (Show Details)
cestes added a subscriber: Unknown Object (MLST).
cestes updated this revision to Diff 10149.Jun 5 2014, 12:30 PM
  • [AArch64] Fix the ordering of the accumulate operand in SchedRW list.
cestes updated this revision to Diff 10150.Jun 5 2014, 12:33 PM

Restoring original diff after accidently submitting another patch
as a new diff for this review.

Hi Dave,

Thanks for working on the scheduling. I'll let Tim and others review the times, but having this is a good beginning.

Though, you could have some more tests, or is that the only difference we know so far is on the SDIV?


cestes added a comment.Jun 6 2014, 8:01 AM

Thanks, Renato. With this patch I wanted to lay the groundwork for future refinements. Specifically, I'm speaking of the myriad SchedWrite types. These represent every combination of latency, micro-op count, and processor resource used by every instruction for the A57. At this point, I haven't actually mapped all of these to individual instructions using SchedRWs and InstRWs; instead I've just relied mostly on the default SchedRWs. I think doing this mapping is a logical next step, but I wanted to get this basic model in the community because won't be able to work on it for another three weeks (looooooong vacation). Hopefully it's a good start and will hold folks over until I get back.

Concerning testing, I totally agree. With both the A53 and A57 sched models, I've really only provided sanity tests. This is mostly because my strategy was to write tests and evaluate the resulting schedules; and such tests are somewhat fragile. A perfect example is the change I just made in another review for the A53 ( I fixed the input operand ordering in the multiply w/ accumulate family of instructions and it caused a barely related test case to fail. That test case was very fragile, as the new schedule was effectively just as good as the previous "correct" schedule. This triggered an idea, and I modified the test case to instead verify the computed latency for successor SUs. Following this approach, it will be much easier to verify the sched model changes for a subtarget without having to worry too much about unrelated patches breaking the test cases.

Anyhow, that was long winded and so the short of it is that I anticipate more test cases in the future...but not for at least three more weeks. :)

atrick accepted this revision.Jun 6 2014, 6:41 PM
atrick edited edge metadata.

I'm not reviewing the A57 spec, but it looks good at the level of machine model defs. There's no fancy composition of SchedWrites, but the straightforward approach looks good to me.

104 ↗(On Diff #10150)

Typo: SchedAlias

This revision is now accepted and ready to land.Jun 6 2014, 6:41 PM
mcrosier closed this revision.Jun 11 2014, 2:15 PM
mcrosier updated this revision to Diff 10333.

Closed by commit rL210705 (authored by @mcrosier).