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.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
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?
cheers,
--renato
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 (http://reviews.llvm.org/D4037). 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. :)
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.
lib/Target/AArch64/AArch64SchedA57.td | ||
---|---|---|
104 ↗ | (On Diff #10150) | Typo: SchedAlias |