The patch at
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01600/vec-tests-avx2_fixes-7.patch
fixes the XPASS, tested on powerpc-apple-darwin9 and x86_64-apple-darwin10.
Thanks,
Dominique
Thanks!
Yes, those xpasses were introduced by the changes in dg-scans I
recently made, but I'm not sure if there is an error in them: in these
three tests compiler for some reason assume that arrays are aligned to
16 byte even in 32-bit mode (AFAIK, ABI requirement for arrays
alignment is alignment
On Mon, Dec 19, 2011 at 9:47 AM, Michael Zolotukhin
wrote:
>> What do you mean no tests require it? For instance, all of the ones
>> that currently pass with with vect_perm?
> Current implementation of vect_perm doesn't check for SSSE3 - so any
> x86 target is supposed to support permutation.
>
>
On Dec 19, 2011, at 10:15 AM, Michael Zolotukhin wrote:
> Thanks, Richard!
> Is anyone else's approve needed for commit?
>
> Michael
>
> On 19 December 2011 20:55, Richard Henderson wrote:
>> On 12/19/2011 12:47 AM, Michael Zolotukhin wrote:
>>> Ok, those were just attempts to adjust dg-scans in
Thanks, Richard!
Is anyone else's approve needed for commit?
Michael
On 19 December 2011 20:55, Richard Henderson wrote:
> On 12/19/2011 12:47 AM, Michael Zolotukhin wrote:
>> Ok, those were just attempts to adjust dg-scans in slp-perm-9.c, in
>> which one more loop was vectorized when compiled
On 12/19/2011 12:47 AM, Michael Zolotukhin wrote:
> Ok, those were just attempts to adjust dg-scans in slp-perm-9.c, in
> which one more loop was vectorized when compiled with -mavx2. In fact,
> just SSSE3 isn't enough for vectorization of this loop - it seems that
> vector size also matters, so I
> What do you mean no tests require it? For instance, all of the ones
> that currently pass with with vect_perm?
Current implementation of vect_perm doesn't check for SSSE3 - so any
x86 target is supposed to support permutation.
> Just leave vect_perm alone for now. That may not be absolutely
>
On 12/16/2011 09:44 AM, Michael Zolotukhin wrote:
>> Why? SSSE3 *really can* do arbitrary permutation. If you say that
>> isn't enough, then there's something wrong in the back end, and all
>> you're doing is papering over a bug.
> Yes, sure, SSSE3 is enough for that. I checked for AVX in vect_pe
> Why? SSSE3 *really can* do arbitrary permutation. If you say that
> isn't enough, then there's something wrong in the back end, and all
> you're doing is papering over a bug.
Yes, sure, SSSE3 is enough for that. I checked for AVX in vect_perm
just because there is no check for SSSE3 and no test
On 12/15/2011 11:21 PM, Michael Zolotukhin wrote:
> E.g., in vect-114.c we need permutation only for reversing vector
> elements, even ssse3 isn't required for it ...
Sure.
> while in slp-perm-9 such permutation isn't enough.
Why? SSSE3 *really can* do arbitrary permutation. If you say that
is
> Well, ppc and spe support arbitrary permutation, which are the only other
> two listed with vec_perm.
>
> As for i386, we support arbitrary permutation beginning with ssse3.
>
> So, don't add vect_any_perm. Use vec_perm and figure out what's really
> wrong with slp-perm-9.
Thanks, that's right,
On 12/15/2011 10:22 AM, Michael Zolotukhin wrote:
>> This is vect_perm. Why are you inventing a new one?
> As far as I understand, vect_perm is true if target supports at least
> some vector-permutation, while vect_any_perm is intended to be true if
> arbitrary permutation is supported (like in av
> This is vect_perm. Why are you inventing a new one?
As far as I understand, vect_perm is true if target supports at least
some vector-permutation, while vect_any_perm is intended to be true if
arbitrary permutation is supported (like in avx). It was introduced
because vectorization began to occu
> +# Return 1 if the target supports instructions for arbitrary permutations.
> +#
> +# This won't change for different subtargets so cache the result.
> +
> +proc check_effective_target_vect_any_perm { } {
This is vect_perm. Why are you inventing a new one?
r~
Uros Bizjak wrote on 15/12/2011 09:56:12 AM:
> On Thu, Dec 15, 2011 at 5:16 AM, Michael Zolotukhin
> wrote:
> > Thanks!
> > Fixed patch is attached.
> >
> > Any other comments?
> >
> > Changelog:
> > 2011-12-14 Michael Zolotukhin
> >
> > * gcc.dg/vect/no-section-anchors-vect-31.c: Ad
On Thu, Dec 15, 2011 at 5:16 AM, Michael Zolotukhin
wrote:
> Thanks!
> Fixed patch is attached.
>
> Any other comments?
>
> Changelog:
> 2011-12-14 Michael Zolotukhin
>
> * gcc.dg/vect/no-section-anchors-vect-31.c: Adjust array size and test
> diag-scans to fix fail on AVX.
>
Thanks!
Fixed patch is attached.
Any other comments?
Changelog:
2011-12-14 Michael Zolotukhin
* 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/
Hello!
Just a nit:
+proc check_prefer_avx128_specified { } {
Please name this function check_prefer_avx128. Nothing was specified anywhere.
Thanks,
Uros.
> 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
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
> 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,
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
On Mon, Dec 12, 2011 at 02:16:04PM +0200, Ira Rosen wrote:
> Michael Zolotukhin wrote on 12/12/2011
> 01:57:09 PM:
>
> >
> > By the way, how could we check if '-mprefer-avx128' was specified from
> > target-supports.exp?
> >
>
> If I understand your question correctly, you can use check-flags (s
Michael Zolotukhin wrote on 12/12/2011
01:57:09 PM:
>
> By the way, how could we check if '-mprefer-avx128' was specified from
> target-supports.exp?
>
If I understand your question correctly, you can use check-flags (see
check_effective_target_arm_fp16_ok_nocache for example).
> Is there any
On Mon, Dec 12, 2011 at 03:57:09PM +0400, Michael Zolotukhin wrote:
> By the way, how could we check if '-mprefer-avx128' was specified from
> target-supports.exp? Is there any global-variable for command line
> options or something similar?
I'd say try some very simple vectorized loop and check h
> I think there is a difference between different vector sizes, and calling
> it vect_X_vector_size_available is not sufficient. Your patch will cause
> failures on ARM. It has two vector sizes, 16 and 8 bytes. E.g., vect-33.c
> gets vectorized with the default vector size, and the alignment messag
gcc-patches-ow...@gcc.gnu.org wrote on 12/12/2011 01:00:52 PM:
> I changed xfails to target-checks - for now I use common
> vect_multiple_sizes (though it'll fail when wider vectors emerge).
> Also, I changed AVX-check to the version Uros suggested. Please check
> updated patch (attached).
>
> A
On Mon, Dec 12, 2011 at 03:00:52PM +0400, Michael Zolotukhin wrote:
> I changed xfails to target-checks - for now I use common
> vect_multiple_sizes (though it'll fail when wider vectors emerge).
> Also, I changed AVX-check to the version Uros suggested. Please check
> updated patch (attached).
>
I changed xfails to target-checks - for now I use common
vect_multiple_sizes (though it'll fail when wider vectors emerge).
Also, I changed AVX-check to the version Uros suggested. Please check
updated patch (attached).
As for vect_multiple_sizes_32B_16B and similar - isn't it too
target-specific?
Hello!
> This patch fixes dg-final scans in tests from vect.exp suite, which
> currently fail when avx2 is used.
--- 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-
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
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'
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/test
33 matches
Mail list logo
