On Wed, Nov 16, 2016 at 6:20 PM, Bin Cheng <bin.ch...@arm.com> wrote: > Hi, > Currently test gfortran.dg/vect/fast-math-mgrid-resid.f checks all predictive > commoning opportunities for all possible loops. This makes it fragile > because vectorizer may peel the loop differently, as well as may choose > different vector factors. For example, on x86-solaris, vectorizer doesn't > peel for prologue loop; for -march=haswell, the case is long time failed > because vector factor is 4, while iteration distance of predictive commoning > opportunity is smaller than 4. This patch refines it by only checking if > predictive commoning variable is created when vector factor is 2; or > vectorization variable is created when factor is 4. This works since we have > only one main loop, and only one vector factor can be used. > Test result checked for various x64 targets. Is it OK?
I think that as you write the test is somewhat fragile. But rather than adjusting the scanning like you do I'd add --param vect-max-peeling-for-alignment=0 and -mprefer-avx128 as additional option on x86_64-*-* i?86-*-*. Your new pattern would fail with avx512 if vector (8) real would be used. What's the actual change that made the testcase fail btw? Richard. > Thanks, > bin > > gcc/testsuite/ChangeLog > 2016-11-16 Bin Cheng <bin.ch...@arm.com> > > PR testsuite/78114 > * gfortran.dg/vect/fast-math-mgrid-resid.f: Refine test by > checking predictive commining variables in vectorized loop > wrto vector factor.
