Re: [Patch] Increase array sizes in vect-tests to enable 256-bit vectorization

[Ira Rosen <IRAR at il dot ibm dot com>]

gcc-patches-owner@gcc.gnu.org wrote on 05/12/2011 10:39:07 AM:

> From: Michael Zolotukhin <michael.v.zolotukhin@gmail.com>
> To: Richard Guenther <richard.guenther@gmail.com>
> Cc: gcc-patches@gcc.gnu.org, izamyatin@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-owner@gcc.gnu.org
>
> On 5 December 2011 10:14, Michael Zolotukhin
> <michael.v.zolotukhin@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.zolotukhin@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.guenther@gmail.com> wrote:
> >> On Sat, Dec 3, 2011 at 5:54 PM, Michael Zolotukhin
> >> <michael.v.zolotukhin@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.guenther@gmail.com> wrote:
> >>>> On Fri, Dec 2, 2011 at 6:39 PM, Michael Zolotukhin
> >>>> <michael.v.zolotukhin@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.guenther@gmail.com>:
> >>>>>> 2011/12/2 Michael Zolotukhin <michael.v.zolotukhin@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.zolotukhin@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.
>