On Tue, Nov 12, 2019 at 8:36 AM Hongtao Liu <crazy...@gmail.com> wrote: > > Hi: > This patch is about to set X86_TUNE_AVX128_OPTIMAL as default for > all AVX target because we found there's still performance gap between > 128-bit auto-vectorization and 256-bit auto-vectorization even with > epilog vectorized. > The performance influence of setting avx128_optimal as default on > SPEC2017 with option `-march=native -funroll-loops -Ofast -flto" on > CLX is as bellow: > > INT rate > 500.perlbench_r -0.32% > 502.gcc_r -1.32% > 505.mcf_r -0.12% > 520.omnetpp_r -0.34% > 523.xalancbmk_r -0.65% > 525.x264_r 2.23% > 531.deepsjeng_r 0.81% > 541.leela_r -0.02% > 548.exchange2_r 10.89% ----------> big improvement > 557.xz_r 0.38% > geomean for intrate 1.10% > > FP rate > 503.bwaves_r 1.41% > 507.cactuBSSN_r -0.14% > 508.namd_r 1.54% > 510.parest_r -0.87% > 511.povray_r 0.28% > 519.lbm_r 0.32% > 521.wrf_r -0.54% > 526.blender_r 0.59% > 527.cam4_r -2.70% > 538.imagick_r 3.92% > 544.nab_r 0.59% > 549.fotonik3d_r -5.44% -------------> regression > 554.roms_r -2.34% > geomean for fprate -0.28% > > The 10% improvement of 548.exchange_r is because there is 9-layer > nested loop, and the loop count for innermost layer is small(enough > for 128-bit vectorization, but not for 256-bit vectorization). > Since loop count is not statically analyzed out, vectorizer will > choose 256-bit vectorization which would never never be triggered. The > vectorization of epilog will introduced some extra instructions, > normally it will bring back some performance, but since it's 9-layer > nested loop, costs of extra instructions will cover the gain. > > The 5.44% regression of 549.fotonik3d_r is because 256-bit > vectorization is better than 128-bit vectorization. Generally when > enabling 256-bit or 512-bit vectorization, there will be instruction > clocksticks reduction also with frequency reduction. when frequency > reduction is less than instructions clocksticks reduction, long vector > width vectorization would be better than shorter one, otherwise the > opposite. The regression of 549.fotonik3d_r is due to this, similar > for 554.roms_r, 528.cam4_r, for those 3 benchmarks, 512-bit > vectorization is best. > > Bootstrap and regression test on i386 is ok. > Ok for trunk?
I don't think 128_optimal does what you think it does. If you want to prefer 128bit AVX adjust the preference, but 128_optimal describes a microarchitectural detail (AVX256 ops are split into two AVX128 ops) and is _not_ intended for "tuning". Richard. > Changelog > gcc/ > * config/i386/i386-option.c (m_CORE_AVX): New macro. > * config/i386/x86-tune.def: Enable 128_optimal for avx and > replace m_SANDYBRIDGE | m_CORE_AVX2 with m_CORE_AVX. > * testsuite/gcc.target/i386/pr84413-1.c: Adjust testcase. > * testsuite/gcc.target/i386/pr84413-2.c: Ditto. > * testsuite/gcc.target/i386/pr84413-3.c: Ditto. > * testsuite/gcc.target/i386/pr70021.c: Ditto. > * testsuite/gcc.target/i386/pr90579.c: New test. > > > -- > BR, > Hongtao