Hi Kyrill,
On 01/23/2018 07:32 AM, Kyrill Tkachov wrote:
Hi Luis,
On 22/01/18 13:46, Luis Machado wrote:
This patch adds a new option to control the minimum stride, for a memory
reference, after which the loop prefetch pass may issue software prefetch
hints for. There are two motivations:
* Make the pass less aggressive, only issuing prefetch hints for
bigger strides
that are more likely to benefit from prefetching. I've noticed a case
in cpu2017
where we were issuing thousands of hints, for example.
I've noticed a large amount of prefetch hints being issued as well, but
had not
analysed it further.
I've gathered some numbers for this. Some of the most extreme cases
before both patches:
CPU2017
xalancbmk_s: 3755 hints
wrf_s: 10950 hints
parest_r: 8521 hints
CPU2006
gamess: 11377 hints
wrf: 3238 hints
After both patches:
CPU2017
xalancbmk_s: 1 hint
wrf_s: 20 hints
parest_r: 0 hints
CPU2006
gamess: 44 hints
wrf: 16 hints
* For processors that have a hardware prefetcher, like Falkor, it
allows the
loop prefetch pass to defer prefetching of smaller (less than the
threshold)
strides to the hardware prefetcher instead. This prevents conflicts
between
the software prefetcher and the hardware prefetcher.
I've noticed considerable reduction in the number of prefetch hints and
slightly positive performance numbers. This aligns GCC and LLVM in
terms of
prefetch behavior for Falkor.
Do you, by any chance, have a link to the LLVM review that implemented
that behavior?
It's okay if you don't, but I think it would be useful context.
I've dug it up. The base change was implemented here:
review: https://reviews.llvm.org/D17945
RFC: http://lists.llvm.org/pipermail/llvm-dev/2015-December/093514.html
And then target-specific changes were introduced later for specific
processors.
One small difference in LLVM is the fact that the second parameter,
prefetching of non-constant strides, is implicitly switched off if one
sets the minimum stride length. My approach here makes that second
parameter adjustable.
I've seen big gains due to prefetching of non-constant strides, but it
tends to be tricky to control and usually comes together with
significant regressions as well.
The fact that we potentially unroll loops along with issuing prefetch
hints also makes things a bit erratic.
The default settings should guarantee no changes for existing targets.
Those
are free to tweak the settings as necessary.
No regressions in the testsuite and bootstrapped ok on aarch64-linux.
Ok?
Are there any benchmark numbers you can share?
I think this approach is sensible.
Comparing the previous, more aggressive, pass behavior with the new one
i've seen a slight improvement for CPU2006, 0.15% for both INT and FP.
For CPU2017 the previous behavior was actually a bit harmful, regressing
performance by about 1.2% in intspeed. The new behavior kept intspeed
stable and slightly improved fpspeed by 0.15%.
The motivation for the future is to have better control of software
prefetching so we can fine-tune the pass, either through generic loop
prefetch code or by using the target-specific parameters.
Since your patch touches generic code as well as AArch64
code you'll need an approval from a midend maintainer as well as an
AArch64 maintainer.
Also, GCC development is now in the regression fixing stage, so unless
this fixes a regression
it may have to wait until GCC 9 development is opened.
That is my understanding. I thought i'd put this up for review anyway so
people can chime in and provide their thoughts.
Thanks for the review.
Luis
