Re: [PATCH v3] Extend the simd function attribute

[Richard Sandiford <richard dot sandiford at arm dot com>]

Szabolcs Nagy <Szabolcs.Nagy@arm.com> writes:
> On 14/11/2019 20:23, Szabolcs Nagy wrote:
>> Sorry v2 had a bug.
>> 
>> v2: added documentation and tests.
>> v3: fixed expand_simd_clones so different isa variants are actually
>>     generated.
>> 
>> GCC currently supports two ways to declare the availability of vector
>> variants of a scalar function:
>> 
>>   #pragma omp declare simd
>>   void f (void);
>> 
>> and
>> 
>>   __attribute__ ((simd))
>>   void f (void);
>> 
>> However these declare a set of symbols that are different simd variants
>> of f, so a library either provides definitions for all those symbols or
>> it cannot use these declarations. (The set of declared symbols can be
>> narrowed down with additional omp clauses, but not enough to allow
>> declaring a single symbol. OpenMP 5 has a declare variant feature that
>> allows declaring more specific simd variants, but it is complicated and
>> still requires gcc or vendor extension for unambiguous declarations.)
>> 
>> This patch extends the gcc specific simd attribute such that it can
>> specify a single vector variant of simple scalar functions (functions
>> that only take and return scalar integer or floating type values):
>> 
>>   __attribute__ ((simd (mask, simdlen, simdabi, name))))
>
> ping.
>
> so the comments so far
>
> - make all attribute arguments mandatory (e.g don't allow
>   simd(mask, simdlen)), this is fine with me if others agree.
>
> - support the linear clause for pointer arguments (sincos).
>   this requires listing arguments to which linear applies,
>   i would only want to do that if there is a hope that it
>   will ever be useful (currently gcc won't vectorize calls
>   with pointer arguments, but maybe it should?). i don't know
>   of a precedent for "list of integers" used in the attribute
>   syntax, so i wonder what's the right way to do it.

This probably isn't helpful, sorry, but the fact that the second point
is a (reasonable) area of debate IMO shows the problems with doing
the first point.  If we go for (1) but not (2), everyone will need
to specify the four initial parameters.  But we'd have to allow (2)
to be optional if we added it later.  We might in future also want other
parameters, e.g. for uniform arguments, by-value vs. by-ref, etc.

Maybe we could have key-value pairs?

  __attribute__((__simd__("simdlen", 2, "simdabi", "n")))

This would also allow linear parameters to be specified like this:

  __attribute__((__simd__("simdlen", 2, "linear", 2, "linear", 3, ...)))

The current attribute syntax doesn't allow { 1, 2 } as an attribute
parameter, and adding it now wouldn't be backward compatible (since
older toolchains should be free to ignore this).

I realise the key-value approach makes things more complicated though.
I guess we're in danger of reinventing omp declare variant that way. :-)

I'm in two minds about whether we should expose the simdabi as the
mangling character.  On the one hand it's simple, on the other it seems
a bit too low-level for something like this.  I think we'd need to check
whether the parameter is valid anyway, so maybe we should have some more
user-friendly mnemonics?

Thanks,
Richard