Differential D5148
[AArch64] Enable partial unrolling and runtime unrolling for AArch64 target Authored by kevin.qin on Sep 2 2014, 3:09 AM.
Details This patch is to enable partial unrolling and runtime unrolling for AArch64 target. Applying this patch with the runtime unrolling prologue changes I just sent together, the SPEC2000 got improved by 0.6%, and for SPEC2006, the improved number is 0.8%. For code size, the images of two benchmarks got same 20% inflation. This experiment is done on A57. Thanks,
Diff Detail Event TimelineComment Actions Can you go into a bit more detail about the benchmarking you did here? What were the size differences? Do you see any notable changes on various benchmarks in particular? Etc. Thanks! Comment Actions Hi Eric, I list the top 5 performance improvements and regressions along with the SPEC2006 Top 5 performance improvements Top 5 regressions geomean changes 99.15% (119.76%) SPEC2000 Top 5 improvements Top 5 regressions geomean changes 99.41% (122.34%) Thanks, Comment Actions I can give more details on the performance regressions here. Basically, partial unrolling contributes small performance improvement, regressions and code size changes. Most of the regressions are caused by the runtime unrolling prologue. This prologue will do some extra work on checking the loop iterations and execute the reminder times of loop bodies. If the runtime unrolled loop is inside another loop, and inner loop count for each running is quite small, then there's a overhead happened in the prologue and caused the regession. Maybe we can do some heuristic work to avoid unrolling such loops, but it's hard to decide which kind of heuristic logic should be used here, because most information can help to make this decision is coming from run time, which is difficult to be estimated at compling time. So maybe it need spend a lot of time to tune and the benefit is unknown. In other hand, the runtime unrolling algorithm is already there and proved to give performance improvments for SPEC2000 and SPEC2006. So I suggest we can enable it first, and then try to get it even better in future. Regards,
Comment Actions Hi, I proposed to set 20 as loop buffer size for A57 after a lot of benchmarking experiments. Then this number will be used as a threshold to allow partial & runtime unrolling on small loops. The effect on spec2006 is, Benchmark | Performance Improvement | Code Size Increment I also did experiments on SPEC2000, but there's no significant performance impact. The geomean code size increment on SPEC2000 is 1.76%, and the increased number on all benchmarks are below 5% except 179.art, which is 14%. Fortunately, it could get partly fixed with my loop prologue simplification patch, and got 9.45% code bloat on 179.art. Overall, this patch can bring 0.4% performance improvement on spec2006 with about 1.8% code size increment, and all code bloats are under 10% after applying another loop prologue simplification patch. So I think it's acceptable for all optimization levels except -Os. Thanks, Comment Actions Looks like the chip itself has a 32 entry loop buffer (with 2 forward and one backward branch support). What range of values did you check here? (i.e. why is 32 not the right value to put here like with the other port specific constants?) Comment Actions By the comments, looks like this is just the value that ended up not bloating too much but still giving some performance. I think this is a lot more acceptable than before, though I'm not sure about when this will run. If this ends up only affecting -O2/3 (maybe even O1), it should be fine. But O0, Os and Oz need to skip anything depending on this. Do we care that the relationship between the two (opt level and buffer size) are undocumented and de-coupled? Comment Actions Hi Renato, Thanks for your review. This patch setted PartialOptSizeThreshold to 0 to disable partial & runtime unrolling on -Os/-Oz. This is implemented in target transform info which makes it effects on aarch64 only. So for A57, the loop buffer size is always 20 at any optimization level, only the way how to use it at different optimization levels makes different. Cheers,
Comment Actions Thanks Kevin. I'm ok with the resulting benchmark numbers. Looking forward for your fix of the remaining 10+% code bloat. cheers, Comment Actions
As I recall, this is related to http://reviews.llvm.org/D5147 -- this is on my TODO list to review again, but feel free to help ;) Thanks again,
Comment Actions Hi, After some performance investigation on smaller granular, I proposed to set 16 as loop buffer size for A57. I will post some experiments result in following comments. Thanks Chandler and Jiangning for their advices. Cheers, Comment Actions Sure. Seems reasonable. One comment I noticed below.
Comment Actions Committed at r219401. Cheers, 2014-10-08 20:52 GMT+01:00 Eric Christopher <echristo@gmail.com>:
| ||||||||||||||||||
I recommend not enabling it this way. Instead, you should set LoopMicroOpBufferSize in the relevant scheduling model. You'll see this is done in lib/Target/X86/X86SchedHaswell.td, for example. This was you can take advantage of the default logic in BasicTargetTransformInfo.cpp (which does things like exclude loops with function calls).
Also, it will force you to pick a threshold, which is really a core-specific property (generally speaking). In my experience, this helps on OOO cores only for small loops. For in-order cores, especially if you use AA during instruction scheduling, it can help for larger loops too (but obviously not *too* large).