gcc-patches-ow...@gcc.gnu.org wrote on 05/12/2011 10:39:07 AM:
> From: Michael Zolotukhin <michael.v.zolotuk...@gmail.com> > To: Richard Guenther <richard.guent...@gmail.com> > Cc: gcc-patches@gcc.gnu.org, izamya...@gmail.com > Date: 05/12/2011 10:39 AM > Subject: Re: [Patch] Increase array sizes in vect-tests to enable > 256-bit vectorization > Sent by: gcc-patches-ow...@gcc.gnu.org > > On 5 December 2011 10:14, Michael Zolotukhin > <michael.v.zolotuk...@gmail.com> wrote: > > Ok, will several tests with short arrays be enough for that or should > > we keep all the original tests plus new ones with longer arrays? > > BTW, there is another problem with current tests with short arrays - > scans are expecting specific number of some diagnostic messages like > "not vectorized: unsupported unaligned store", and that number would > be different if several vector-lengths are available - so we'll have > fails in those tests. There is vect_multiple_sizes for such cases. Ira > > What is a right way to handle this? Currently I see two ways of doing > it. One way is to just extend array sizes (as I did in the sent > patch), the other way is to remove such scans from all tests > (replacing them with some more general scans). If we are going to > rewrite the scans, we need to be able to distinguish cases when > several lengths are available - for now it looks unclear how to do > this – at the first glance we could add length checkers in > lib/support_targets.exp but this solution seems not quite good. > > What's your opinion on that? > > Best Regards, Michael. > > On 5 December 2011 10:14, Michael Zolotukhin > <michael.v.zolotuk...@gmail.com> wrote: > > Ok, will several tests with short arrays be enough for that or should > > we keep all the original tests plus new ones with longer arrays? > > > > Michael > > > > On 4 December 2011 15:44, Richard Guenther > <richard.guent...@gmail.com> wrote: > >> On Sat, Dec 3, 2011 at 5:54 PM, Michael Zolotukhin > >> <michael.v.zolotuk...@gmail.com> wrote: > >>>> I mean, that, when 256-bit vectorization is enabled we still use 128bit > >>>> vectorization if the arrays are too short for 256bit > vectorization. You'll > >>>> lose this test coverage when you change the array sizes. > >>> That's true, but do we need all these test both with short and long > >>> arrays? We could have the tests with increased sizes and compile them > >>> with/without use of avx, thus testing both 256- and 128- bit > >>> vectorization. Additionally, we might want to add several tests with > >>> short arrays to check what happens if 256-bit is available, but arrays > >>> is too short for it. I mean we don't need to duplicate all of the > >>> tests to check this situation. > >> > >> Well, initially those tests served as a way to prove that dual-size > >> vectorization > >> works. You should not remove this testing functionality. > >> > >> Richard. > >> > >>> On 3 December 2011 18:31, Richard Guenther > <richard.guent...@gmail.com> wrote: > >>>> On Fri, Dec 2, 2011 at 6:39 PM, Michael Zolotukhin > >>>> <michael.v.zolotuk...@gmail.com> wrote: > >>>>>> > >>>>>> Shouldn't we add a variant for each testcase so that we still > >>>>>> excercise both 128-bit and 256-bit vectorization paths? > >>>>> > >>>>> These tests are still good to test 128-bit vectorization, the changes > >>>>> was made just to make sure that 256-bit vectorization is possible on > >>>>> the tests. > >>>>> > >>>>> Actually, It's just first step in enabling these tests for 256 bits - > >>>>> for now many of them are failing if '-mavx' or '-mavx2' is specified > >>>>> (mostly due to different diagnostics messages produced by vectorizer), > >>>>> but with original (small) sizes of arrays we couldn't even check that. > >>>>> When they are enabled, it'll be possible to use them for testing both > >>>>> 128- and 256- bit vectorization. > >>>> > >>>> I mean, that, when 256-bit vectorization is enabled we still use 128bit > >>>> vectorization if the arrays are too short for 256bit > vectorization. You'll > >>>> lose this test coverage when you change the array sizes. > >>>> > >>>> Richard. > >>>> > >>>>> Michael > >>>>> > >>>>> > >>>>> 2011/12/2 Richard Guenther <richard.guent...@gmail.com>: > >>>>>> 2011/12/2 Michael Zolotukhin <michael.v.zolotuk...@gmail.com>: > >>>>>>> Hi, > >>>>>>> > >>>>>>> This patch increases array sizes in tests from vect.exp suite, thus > >>>>>>> enabling 256-bit vectorization where it's available. > >>>>>>> > >>>>>>> Ok for trunk? > >>>>>> > >>>>>> Shouldn't we add a variant for each testcase so that we still > >>>>>> excercise both 128-bit and 256-bit vectorization paths? > >>>>>> > >>>>>>> Changelog: > >>>>>>> 2011-12-02 Michael Zolotukhin <michael.v.zolotuk...@intel.com> > >>>>>>> > >>>>>>> * gcc.dg/vect/slp-13.c: Increase array size, add > initialization. > >>>>>>> * gcc.dg/vect/slp-24.c: Ditto. > >>>>>>> * gcc.dg/vect/slp-3.c: Likewise and fix scans. > >>>>>>> * gcc.dg/vect/slp-34.c: Ditto. > >>>>>>> * gcc.dg/vect/slp-4.c: Ditto. > >>>>>>> * gcc.dg/vect/slp-cond-2.c: Ditto. > >>>>>>> * gcc.dg/vect/slp-multitypes-11.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-1.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-10.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-105.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-112.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-15.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-2.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-31.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-32.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-33.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-34.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-35.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-36.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-6.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-73.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-74.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-75.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-76.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-80.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-85.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-89.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-97.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-98.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-all.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-double-reduc-6.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-iv-8.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-iv-8a.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-1.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-1a.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-1b.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-2.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-2a.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-2c.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-3.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-3a.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-4a.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-4b.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-4c.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-4d.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-4m.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-fir-lb.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-outer-fir.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-over-widen-1.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-over-widen-2.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-over-widen-3.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-over-widen-4.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-reduc-1char.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-reduc-2char.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-reduc-pattern-1b.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-reduc-pattern-1c.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-reduc-pattern-2b.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-shift-2.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-strided-a-u8-i8-gap2.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-strided-a-u8-i8-gap7.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-strided-u8-i8-gap2.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-strided-u8-i8-gap4.c: Ditto. > >>>>>>> * gcc.dg/vect/vect-strided-u8-i8-gap7.c: Ditto. > >>>>>>> > >>>>>>> -- > >>>>>>> --- > >>>>>>> Best regards, > >>>>>>> Michael V. Zolotukhin, > >>>>>>> Software Engineer > >>>>>>> Intel Corporation. > >>> > >>> -- > >>> --- > >>> Best regards, > >>> Michael V. Zolotukhin, > >>> Software Engineer > >>> Intel Corporation. > > > > -- > --- > Best regards, > Michael V. Zolotukhin, > Software Engineer > Intel Corporation. >
