[llvm-dev] Enable vectorizer-maximize-bandwidth by default?

Dehao Chen via llvm-dev llvm-dev at lists.llvm.org
Thu May 18 15:30:27 PDT 2017


Hi,

I'm proposing to make vectorizer-maximize-bandwidth on by default for loop
vectorizer because it should generally help performance.

I've tested the performance impact on Intel sandybridge machine with
speccpu benchmarks:

           Benchmark             Base:Reference   (1)
-------------------------------------------------------
spec/2006/fp/C++/444.namd                 26.84  -0.31%
spec/2006/fp/C++/447.dealII               46.19  +0.89%
spec/2006/fp/C++/450.soplex               42.92  -0.44%
spec/2006/fp/C++/453.povray               38.57  -2.25%
spec/2006/fp/C/433.milc                   24.54  -0.76%
spec/2006/fp/C/470.lbm                    41.08  +0.26%
spec/2006/fp/C/482.sphinx3                47.58  -0.99%
spec/2006/int/C++/471.omnetpp             22.06  +1.87%
spec/2006/int/C++/473.astar               22.65  -0.12%
spec/2006/int/C++/483.xalancbmk           33.69  +4.97%
spec/2006/int/C/400.perlbench             33.43  +1.70%
spec/2006/int/C/401.bzip2                 23.02  -0.19%
spec/2006/int/C/403.gcc                   32.57  -0.43%
spec/2006/int/C/429.mcf                   40.35  +0.27%
spec/2006/int/C/445.gobmk                 26.96  +0.06%
spec/2006/int/C/456.hmmer                  24.4  +0.19%
spec/2006/int/C/458.sjeng                 27.91  -0.08%
spec/2006/int/C/462.libquantum            57.47  -0.20%
spec/2006/int/C/464.h264ref               46.52  +1.35%

geometric mean                                   +0.29%

  Scores are benchmark specific.

We do have regression on 453.povray, but it's due to secondary effects as
all hot functions are the same. I've also tested the code size impact, it
does not change for tested speccpu benchmarks.

I've prepared https://reviews.llvm.org/D33341 to do this.

I really appreciate if the community can help test the performance impact
of this change on other architectures so that we can decide if this should
go target-dependent.

Any comments/concerns?

Thanks,
Dehao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170518/0a56b7de/attachment.html>


More information about the llvm-dev mailing list