2016-06-16 8:06 GMT+03:00 Jeff Law <l...@redhat.com>: > On 05/20/2016 05:40 AM, Ilya Enkovich wrote: >> >> 2016-05-20 14:17 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >>> >>> On Fri, May 20, 2016 at 11:50 AM, Ilya Enkovich <enkovich....@gmail.com> >>> wrote: >>>> >>>> 2016-05-20 12:26 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >>>>> >>>>> On Thu, May 19, 2016 at 9:36 PM, Ilya Enkovich <enkovich....@gmail.com> >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> This patch introduces new options used for loop epilogues >>>>>> vectorization. >>>>> >>>>> >>>>> Why's that? This is a bit too much for the casual user and if it is >>>>> really necessary >>>>> to control this via options then it is not fine-grained enough. >>>>> >>>>> Why doesn't the vectorizer/backend have enough info to decide this >>>>> itself? >>>> >>>> >>>> I don't expect casual user to decide which modes to choose. These >>>> controls are >>>> added for debugging and performance measurement purposes. I see now I >>>> miss >>>> -ftree-vectorize-epilogues aliased to -ftree-vectorize-epilogues=all. >>>> Surely >>>> I expect epilogues and short loops vectorization be enabled by default >>>> on -O3 >>>> or by -ftree-vectorize-loops. >>> >>> >>> Can you make all these --params then? I think to be useful to users we'd >>> want >>> them to be loop pragmas rather than options. >> >> >> OK, I'll change it to params. I didn't think about control via >> pragmas but will do now. > > So the questions I'd like to see answered: > > 1. You've got 3 modes for epilogue vectorization. Is this an artifact of > not really having good heuristics yet for which mode to apply to a > particular loop at this time? > > 2. Similarly for cost models.
All three modes are profitable in different situations. Profitable mode depends on a loop structure and target capabilities. Ultimate goal is to have all three modes enabled by default. I can't state current heuristics are good enough for all cases and targets and therefore don't enable epilogues vectorization by default for now. This is to be measured, analyzed and tuned in time for GCC 7.1. I add cost model simply to have an ability to force epilogue vectorization for stability testing (force some mode of epilogue vectorization and check nothing fails) and performance testing/tuning (try to find cases where we may benefit from epilogue vectorization but don't due to bad cost model). Also I don't want to force epilogue vectorization for all loops for which vectorization is forced using unlimited cost model because that may hurt performance for simd loops. > > In the cover message you indicated you were getting expected gains of KNL, > but not on Haswell. Do you have any sense yet why you're not getting good > resuls on Haswell yet? For KNL are you getting those speedups with a > generic set of options or are those with a custom set of options to set the > mode & cost models? Currently I have numbers collected on various suites for KNL machine. Masking mode (-ftree-vectorize-epilogues=mask) shows not bad results (dynamic cost model, -Ofast -flto -funroll-loops). I don't see significant losses and there are few significant gains. For combine and nomask modes the result is not good enough yet - there are several significant performance losses. My guess is that current threshold for combine is way too high and for nomask variant we better choose the smallest vector size for epilogues instead of the next available (use zmm for body and xmm for epilogue instead of zmmm for body and ymm for epilogue). ICC shows better results in these modes which makes me believe we can tune them as well. Overall nomask mode shows worse results comparing to options with masking which is quite expected for KNL. Unfortunately some big gains demonstrated by ICC are not reproducible using GCC because we originally can't vectorize required hot loops. E.g. on 200.sixtrack GCC has nothing and ICC has ~40% for all three modes. I don't have the whole statistics for Haswell but synthetic tests show the situation is really different from KNL. Even for the 'perfect' iterations count number (VF * 2 - 1) scalar version of epilogue shows the same result as a masked one. It means ratio of vector code performance vs. scalar code performance is not as high as for KNL (KNL is more vector oriented and has weaker scalar performance, double vector size also matters here) and masking cost is higher for Haswell. We still focus on AVX-512 targets more because of their rich masking capabilities and wider vector. Thanks, Ilya > > jeff
