- User Since
- Feb 14 2014, 2:45 PM (348 w, 3 d)
Mar 4 2015
Mar 3 2015
Oct 22 2014
Sep 29 2014
Committed as r218627.
Sep 26 2014
Excellent. Thanks, Jiangning. Your new numbers show a regressions in gap and equake. I'll try to get an equake number, but I do know that we're seeing ~1% gain. Interestingly enough one of the regressions that we're seeing is on twolf, but your device shows a gain. :) Despite the differences, I too think this latest patch looks like a good foundation for future work.
Sep 24 2014
This new patchset moves the model back to out-of-order yet restricts the issue-width to the minimum of the actual issue width and dispatch width as Andy suggested. It brought the Spec2000/2006 numbers back up and even outperformed the original model by a few percent (geomean). It also improved the EEMBC numbers by a percent (geomean). I did see some degradation in individual tests, but nothing horrible. It will take some more detailed analysis to determine the cause there.
Sep 23 2014
Update changes from 3-way issue in-order to 3-way issue out-of-
Sep 18 2014
I did some more runs and I've got mixed news. Seems I've been a bit more
focused on this new model's gains over -mcpu=generic rather than using
the existing A57 model as a baseline. The reason was primarily because
our earlier testing showed the existing A57 model performing very
poorly. However, I re-did my runs using the existing A57 model as a
baseline and it actually performs really well. So that's the good news.
The mediocre news is that increasing the accuracy of the model has
merely shifted performance around and not actually increased it.
Sep 17 2014
Setting IssueWidth=3 is correct. That really means how many micro-ops can be "handled" per cycle. So it should be the minimum of decode/issue width. To be precise, we should have a decodeWidth that counts instructions, but I never bothered to add it since IssueWidth can serve the same purpose.
I'm seeing strong improvements for Spec2000 on device here, so I'll try ToT too and get to the bottom of this.
Sep 16 2014
Jun 6 2014
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.
Jun 5 2014
Updated lit test to just check the computed latencies instead of final schedule. This
will make the test case more robust to future scheduling changes.
Restoring original diff after accidently submitting another patch
as a new diff for this review.
- [AArch64] Fix the ordering of the accumulate operand in SchedRW list.
Jun 3 2014
May 19 2014
May 16 2014
Accidentally committed the patchset without the recommended revisions from Tim. Will submit with a subsequent patchset that adds these revisions and also resolves http://llvm.org/bugs/show_bug.cgi?id=19761.
May 15 2014
Removing commented out code.
Explicitly checking Opcodes in the helper function(s) for shifting/extending.