| Message ID | 20111212074628.GG1957@tyan-ft48-01.lab.bos.redhat.com |
|---|---|
| State | New |
| Headers | show |
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
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
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~
> 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~
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~
> 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~
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" } } */