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