> 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.
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.
