Hi Jakub,
On 3 June 2016 at 19:33, Jakub Jelinek <ja...@redhat.com> wrote:
> On Tue, Jan 12, 2016 at 05:21:37PM +0300, Ilya Enkovich wrote:
>> > --- gcc/tree-vect-slp.c.jj 2016-01-08 21:45:57.000000000 +0100
>> > +++ gcc/tree-vect-slp.c 2016-01-11 12:07:19.633366712 +0100
>> > @@ -2999,12 +2999,9 @@ vect_get_constant_vectors (tree op, slp_
>> > gimple *init_stmt;
>> > if (VECTOR_BOOLEAN_TYPE_P (vector_type))
>> > {
>> > - gcc_assert (fold_convertible_p (TREE_TYPE
>> > (vector_type),
>> > - op));
>> > + gcc_assert (INTEGRAL_TYPE_P (TREE_TYPE (op)));
>> > init_stmt = gimple_build_assign (new_temp, NOP_EXPR,
>> > op);
>>
>> In vect_init_vector we had to introduce COND_EXPR to choose between 0 and -1
>> for
>> boolean vectors. Shouldn't we do similar in SLP?
>
> Apparently the answer to this is YES.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/6.2?
>
> 2016-06-03 Jakub Jelinek <ja...@redhat.com>
>
> PR tree-optimization/71259
> * tree-vect-slp.c (vect_get_constant_vectors): For
> VECTOR_BOOLEAN_TYPE_P, return all ones constant instead of
> one for constant op, and use COND_EXPR for non-constant.
>
> * gcc.dg/vect/pr71259.c: New test.
>
> --- gcc/tree-vect-slp.c.jj 2016-05-24 10:56:02.000000000 +0200
> +++ gcc/tree-vect-slp.c 2016-06-03 17:01:12.740955935 +0200
> @@ -3056,7 +3056,7 @@ vect_get_constant_vectors (tree op, slp_
> if (integer_zerop (op))
> op = build_int_cst (TREE_TYPE (vector_type), 0);
> else if (integer_onep (op))
> - op = build_int_cst (TREE_TYPE (vector_type), 1);
> + op = build_all_ones_cst (TREE_TYPE (vector_type));
> else
> gcc_unreachable ();
> }
> @@ -3071,8 +3071,14 @@ vect_get_constant_vectors (tree op, slp_
> gimple *init_stmt;
> if (VECTOR_BOOLEAN_TYPE_P (vector_type))
> {
> + tree true_val
> + = build_all_ones_cst (TREE_TYPE (vector_type));
> + tree false_val
> + = build_zero_cst (TREE_TYPE (vector_type));
> gcc_assert (INTEGRAL_TYPE_P (TREE_TYPE (op)));
> - init_stmt = gimple_build_assign (new_temp, NOP_EXPR,
> op);
> + init_stmt = gimple_build_assign (new_temp, COND_EXPR,
> + op, true_val,
> + false_val);
> }
> else
> {
> --- gcc/testsuite/gcc.dg/vect/pr71259.c.jj 2016-06-03 17:05:37.693475438
> +0200
> +++ gcc/testsuite/gcc.dg/vect/pr71259.c 2016-06-03 17:05:32.418544731 +0200
> @@ -0,0 +1,28 @@
> +/* PR tree-optimization/71259 */
> +/* { dg-do run } */
> +/* { dg-options "-O3" } */
> +/* { dg-additional-options "-mavx" { target avx_runtime } } */
> +
> +#include "tree-vect.h"
> +
> +long a, b[1][44][2];
> +long long c[44][17][2];
> +
> +int
> +main ()
> +{
> + int i, j, k;
> + check_vect ();
> + asm volatile ("" : : : "memory");
> + for (i = 0; i < 44; i++)
> + for (j = 0; j < 17; j++)
> + for (k = 0; k < 2; k++)
> + c[i][j][k] = (30995740 >= *(k + *(j + *b)) != (a != 8)) -
> 5105075050047261684;
> + asm volatile ("" : : : "memory");
> + for (i = 0; i < 44; i++)
> + for (j = 0; j < 17; j++)
> + for (k = 0; k < 2; k++)
> + if (c[i][j][k] != -5105075050047261684)
> + __builtin_abort ();
> + return 0;
> +}
>
This new test fails on ARM targets where the default FPU is not Neon like.
The error message I'm seeing is:
In file included from
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.dg/vect/pr71259.c:6:0:
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.dg/vect/tree-vect.h:
In function 'check_vect':
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.dg/vect/tree-vect.h:65:5:
error: inconsistent operand constraints in an 'asm'
Well, the same error message actually appears with other tests, I did
notice this one because
it is a new one.
The arm code is:
/* On some processors without NEON support, this instruction may
be a no-op, on others it may trap, so check that it executes
correctly. */
long long a = 0, b = 1;
asm ("vorr %P0, %P1, %P2"
: "=w" (a)
: "0" (a), "w" (b));
... which has been here since 2007 :(
IIUC, its purpose is to check Neon availability, but this makes the
tests fail instead of
being unsupported.
Why not use an effective-target check instead?
Christophe.
>
> Jakub
