Re: [r13-7135 Regression] FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r] [^\\n]* = foo\\.simdclone" 2 on Linux/x86_64

["Andre Vieira (lists)" <andre.simoesdiasvieira@arm.com>]

On 14/04/2023 12:47, Richard Biener wrote:
> On Fri, Apr 14, 2023 at 11:42 AM Andre Vieira (lists)
> <andre.simoesdiasvieira@arm.com> wrote:
>>
>>
> 
> Ah, but then vect_get_smallest_scalar_type should simply ignore that
> pointer in MASK_CALL.  It should only look at the arguments relevant
> for vectorization.  So
> 
> diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
> index 8daf7bd7dd3..70bb8595951 100644
> --- a/gcc/tree-vect-data-refs.cc
> +++ b/gcc/tree-vect-data-refs.cc
> @@ -165,6 +165,8 @@ vect_get_smallest_scalar_type (stmt_vec_info
> stmt_info, tree scalar_type)
>              }
>            else if (internal_fn_mask_index (ifn) == 0)
>              i = 1;
> +         else if (ifn == IFN_MASK_CALL)
> +           i = 1;
>          }
>         if (i < gimple_call_num_args (call))
>          {
> 
> ?

The problem with that is that not all arguments of a simdclone are 
mapped to vectors, for instance if one of them is 'uniform' then it's 
passed as a single scalar as uniform says it won't change between 
iteration, thus it has no effect on VF.

End of the day, the logic behind VF selection for simd clones is very 
different to that of a normal statement. Take for instance the logic 
behind simdlen selection for SVE, its not yet in trunk, where we select 
the number of elements to handle based on the widest element type. So say a:
#pragma omp declare simd
int foo (int, long long);

would have 4 NEON simd clones with (based on Narrowest element type):
/* 128 bit */
V4SI foo (V4SI, V4DI)
V4SI foo (V4SI, V4DI, V4BI)
/* 64 bit */
V2SI foo (V2SI, V2DI)
V2SI foo (V2SI, V2DI, V2BI)

and SVE (based on Widest element type):
VNx2SI foo (VN2xSI, VN2xDI, VN2xBI)

This also shows how basing this on the return value wouldn't quite work 
either for SVE :(

For now I think all targets base the selection on narrowest element type 
and I think we could get away with only looking at the types that map to 
vectors using the simdclone information, that's a pretty straight 
forward change to the existing code I think. And I'll make sure to come 
up with a way of dealing with this in a more robust way for SVE to work.

I'll try to write something up, but probably won't be able to post it 
until Monday.

Kind regards,
Andre