Patchwork Adjust diag-scans in vect-tests to fix fails on AVX/AVX2

login
register
mail settings
Submitter Jakub Jelinek
Date Dec. 12, 2011, 7:46 a.m.
Message ID <20111212074628.GG1957@tyan-ft48-01.lab.bos.redhat.com>
Download mbox | patch
Permalink /patch/130656/
State New
Headers show

Comments

Jakub Jelinek - Dec. 12, 2011, 7:46 a.m.
On Mon, Dec 12, 2011 at 11:06:37AM +0400, Michael Zolotukhin wrote:

The xfails are IMHO undesriable, then you just stop testing those tests on
very common developer platforms.
IMHO you should just use different dump-times count for the
vect_multipl_sizes (after checking it is the right count), if it doesn't
depend on -mprefer-avx128 vs. -mno-prefer-avx128.  If it does,
then perhaps we want a predicate that details the vectorization factors
and their order.

	Jakub
Michael Zolotukhin - Dec. 12, 2011, 8 a.m.
The problem is that when vect_multiple_sizes is true, then no correct
number exist (at least, theoretically). That's because number of
diagnostic messages depends on number of available vector sizes - for
now this number is usually 2 (on x86 it's 256 and 128 bit vectors), so
we could change 'xfail' to 'target'. But when wider vectors become
available (512 bit), there will be fails again.

On 12 December 2011 11:46, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Dec 12, 2011 at 11:06:37AM +0400, Michael Zolotukhin wrote:
> diff --git a/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c b/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
> index 21b87a3..f75253e 100644
> --- a/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
> +++ b/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
> @@ -88,5 +88,6 @@ int main (void)
>
>  /* { dg-final { scan-tree-dump-times "vectorized 4 loops" 1 "vect" } } */
>  /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" } } */
> -/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 2 "vect" } } */
> +/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 2 "vect" { target {! vect_multiple_sizes} } } } */
> +/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 2 "vect" { xfail  vect_multiple_sizes} } } */
>  /* { dg-final { cleanup-tree-dump "vect" } } */
>
> The xfails are IMHO undesriable, then you just stop testing those tests on
> very common developer platforms.
> IMHO you should just use different dump-times count for the
> vect_multipl_sizes (after checking it is the right count), if it doesn't
> depend on -mprefer-avx128 vs. -mno-prefer-avx128.  If it does,
> then perhaps we want a predicate that details the vectorization factors
> and their order.
>
>        Jakub
Jakub Jelinek - Dec. 12, 2011, 8:07 a.m.
On Mon, Dec 12, 2011 at 12:00:47PM +0400, Michael Zolotukhin wrote:
> The problem is that when vect_multiple_sizes is true, then no correct
> number exist (at least, theoretically). That's because number of
> diagnostic messages depends on number of available vector sizes - for
> now this number is usually 2 (on x86 it's 256 and 128 bit vectors), so
> we could change 'xfail' to 'target'. But when wider vectors become
> available (512 bit), there will be fails again.

Which is why introducing
vect_multiple_sizes_32B_16B (for -mno-prefer-128) and
vect_multiple_sizes_16B_32B (for -mprefer-128) and using it in the tests
could solve it.

	Jakub
Richard Henderson - Dec. 12, 2011, 8:46 p.m.
On 12/12/2011 12:07 AM, Jakub Jelinek wrote:
> Which is why introducing
> vect_multiple_sizes_32B_16B (for -mno-prefer-128) and
> vect_multiple_sizes_16B_32B (for -mprefer-128) and using it in the tests
> could solve it.

And even this is insufficient, since you need to distinguish between multiple integer vector sizes and multiple fp vector sizes, aka AVX vs AVX2.


r~
Michael Zolotukhin - Dec. 13, 2011, 5:44 a.m.
> And even this is insufficient, since you need to distinguish between multiple integer vector sizes and multiple fp vector sizes, aka AVX vs AVX2.

Should we introduce checks for each possible vector datatype (e.g.
vect_8byte_int_available, vect_16byte_int_available,
vect_32byte_int_available, vect_16byte_float_available,
vect_32byte_float_available etc.) along with a check for
prefer_something (e.g. vect_prefer_16byte)? Having such info, we'll be
able to distinguish all the cases, right?

On 13 December 2011 00:46, Richard Henderson <rth@redhat.com> wrote:
> On 12/12/2011 12:07 AM, Jakub Jelinek wrote:
>> Which is why introducing
>> vect_multiple_sizes_32B_16B (for -mno-prefer-128) and
>> vect_multiple_sizes_16B_32B (for -mprefer-128) and using it in the tests
>> could solve it.
>
> And even this is insufficient, since you need to distinguish between multiple integer vector sizes and multiple fp vector sizes, aka AVX vs AVX2.
>

> r~
Richard Henderson - Dec. 13, 2011, 5:14 p.m.
On 12/12/2011 09:44 PM, Michael Zolotukhin wrote:
> Should we introduce checks for each possible vector datatype (e.g.
> vect_8byte_int_available, vect_16byte_int_available,
> vect_32byte_int_available, vect_16byte_float_available,
> vect_32byte_float_available etc.) along with a check for
> prefer_something (e.g. vect_prefer_16byte)? Having such info, we'll be
> able to distinguish all the cases, right?

Meh.  This seems excruciatingly error prone.

I think we should simply re-write the test cases so that it doesn't
matter how many times we see a particular string.  Don't combine so
many (potentially vectorizable) loops within a test case that it matters.


r~
Michael Zolotukhin - Dec. 14, 2011, 12:36 p.m.
> Meh.  This seems excruciatingly error prone.
>
> I think we should simply re-write the test cases so that it doesn't
> matter how many times we see a particular string.  Don't combine so
> many (potentially vectorizable) loops within a test case that it matters.

Some rework on tests looks better to me too - actually, recently
commited array sizes increase was intended to partly solve this
problem.
Though, in some cases it isn't enough - e.g. when a test checks if an
access is aligned (it could be aligned to 128-bit, but not to
256-bit).

I attach a patch, where I changed dg-scans in several tests: where
possible, I tried to replace dg-scan-times with dg-scan, also avoided
use of 'vect_multiple_size' due to problems discussed above.

This patch fixes all fails in vect.exp, which occur when '-mavx2' is
used, except one (see PR51508). There are still fails when
'-mprefer-avx128' is specified, but I think we could return to this
issue later.

Is it ok for trunk?

Changelog:
2011-12-14  Michael Zolotukhin  <michael.v.zolotukhin@intel.com>

        * gcc.dg/vect/no-section-anchors-vect-31.c: Adjust array size and test
        diag-scans to fix fail on AVX.
        * gcc.dg/vect/no-section-anchors-vect-36.c: Ditto.
        * gcc.dg/vect/no-section-anchors-vect-64.c: Ditto.
        * gcc.dg/vect/no-section-anchors-vect-66.c: Ditto.
        * gcc.dg/vect/no-section-anchors-vect-68.c: Ditto.
        * gcc.dg/vect/no-section-anchors-vect-69.c: Ditto.
        * gcc.dg/vect/no-vfa-vect-dv-2.c: Adjust dg-scans.
        * gcc.dg/vect/pr45752.c: Ditto.
        * gcc.dg/vect/slp-perm-4.c: Ditto.
        * gcc.dg/vect/slp-perm-9.c: Ditto.
        * gcc.dg/vect/vect-33.c: Ditto.
        * gcc.dg/vect/vect-35.c: Ditto.
        * gcc.dg/vect/vect-6-big-array.c: Ditto.
        * gcc.dg/vect/vect-6.c: Ditto.
        * gcc.dg/vect/vect-91.c: Ditto.
        * gcc.dg/vect/vect-all-big-array.c: Ditto.
        * gcc.dg/vect/vect-all.c: Ditto.
        * gcc.dg/vect/vect-multitypes-1.c: Ditto.
        * gcc.dg/vect/vect-outer-4c.c: Ditto.
        * gcc.dg/vect/vect-outer-5.c: Ditto.
        * gcc.dg/vect/vect-over-widen-1.c: Ditto.
        * gcc.dg/vect/vect-over-widen-3.c: Ditto.
        * gcc.dg/vect/vect-over-widen-4.c: Ditto.
        * gcc.dg/vect/vect-peel-1.c: Ditto.
        * gcc.dg/vect/vect-peel-2.c: Ditto.
        * gcc.dg/vect/vect-peel-3.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/wrapv-vect-reduc-pattern-2c.c: Ditto.
        * lib/target-supports.exp
(check_effective_target_vect_any_perm): New function.
        (check_avx_available): Ditto.
        (check_effective_target_vect_sizes_32B_16B): Ditto.
        (check_prefer_avx128_specified): Ditto.
        (check_effective_target_vect_aligned_arrays): Add handling of AVX.
        (check_effective_target_vect_multiple_sizes): Ditto.


On 13 December 2011 21:14, Richard Henderson <rth@redhat.com> wrote:
> On 12/12/2011 09:44 PM, Michael Zolotukhin wrote:
>> Should we introduce checks for each possible vector datatype (e.g.
>> vect_8byte_int_available, vect_16byte_int_available,
>> vect_32byte_int_available, vect_16byte_float_available,
>> vect_32byte_float_available etc.) along with a check for
>> prefer_something (e.g. vect_prefer_16byte)? Having such info, we'll be
>> able to distinguish all the cases, right?
>
> Meh.  This seems excruciatingly error prone.
>
> I think we should simply re-write the test cases so that it doesn't
> matter how many times we see a particular string.  Don't combine so
> many (potentially vectorizable) loops within a test case that it matters.
>
> r~

Patch

diff --git a/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c b/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
index 21b87a3..f75253e 100644
--- a/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
+++ b/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
@@ -88,5 +88,6 @@  int main (void)
 
 /* { dg-final { scan-tree-dump-times "vectorized 4 loops" 1 "vect" } } */
 /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" } } */
-/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 2 "vect" } } */
+/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 2 "vect" { target {! vect_multiple_sizes} } } } */
+/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 2 "vect" { xfail  vect_multiple_sizes} } } */
 /* { dg-final { cleanup-tree-dump "vect" } } */