+cc auto-vectorizer maintainers. David
On Mon, Aug 19, 2013 at 10:37 AM, Cong Hou <co...@google.com> wrote: > Nowadays, SIMD instructions play more and more important roles in our > daily computations. AVX and AVX2 have extended 128-bit registers to > 256-bit ones, and the newly announced AVX-512 further doubles the > size. The benefit we can get from vectorization will be larger and > larger. This is also a common practice in other compilers: > > 1) Intel's ICC turns on vectorizer at O2 by default and it has been > the case for many years; > > 2) Most recently, LLVM turns it on for both O2 and Os. > > > Here we propose moving vectorization from -O3 to -O2 in GCC. Three > main concerns about this change are: 1. Does vectorization greatly > increase the generated code size? 2. How much performance can be > improved? 3. Does vectorization increase compile time significantly? > > > I have fixed GCC bootstrap failure with vectorizer turned on > (http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00497.html). To evaluate > the size and performance impact, experiments on SPEC06 and internal > benchmarks are done. Based on the data, I have tuned the parameters > for vectorizer which reduces the code bloat without sacrificing the > performance gain. There are some performance regressions in SPEC06, > and the root cause has been analyzed and understood. I will file bugs > tracking them independently. The experiments failed on three > benchmarks (please refer to > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993). The experiment > result is attached here as two pdf files. Below are our summaries of > the result: > > > 1) We noticed that vectorization could increase the generated code > size, so we tried to suppress this problem by doing some tunings, > which include setting a higher loop bound so that loops with small > iterations won't be vectorized, and disabling loop versioning. The > average size increase is decreased from 9.84% to 7.08% after our > tunings (13.93% to 10.75% for Fortran benchmarks, and 3.55% to 1.44% > for C/C++ benchmarks). The code size increase for Fortran benchmarks > can be significant (from 18.72% to 34.15%), but the performance gain > is also huge. Hence we think this size increase is reasonable. For > C/C++ benchmarks, the size increase is very small (below 3% except > 447.dealII). > > > 2) Vectorization improves the performance for most benchmarks by > around 2.5%-3% on average, and much more for Fortran benchmarks. On > Sandybridge machines, the improvement can be more if using > -march=corei7 (3.27% on average) and -march=corei7-avx (4.81% on > average) (Please see the attachment for details). We also noticed that > some performance degrades exist, and after investigation, we found > some are caused by the defects of GCC's vectorization (e.g. GCC's SLP > could not vectorize a group of accesses if the number of group cannot > be divided by VF http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49955, > and any data dependence between statements can prevent vectorization), > which can be resolved in the future. > > > 3) As last, we found that introducing vectorization almost does not > affect the build time. GCC bootstrap time increase is negligible. > > > As a reference, Richard Biener is also proposing to move vectorization > to O2 by improving the cost model > (http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00904.html). > > > Vectorization has great performance potential -- the more people use > it, the likely it will be further improved -- turning it on at O2 is > the way to go ... > > > Thank you! > > > Cong Hou
