Re: [RFC PATCH] Extend the simd function attribute

[Szabolcs Nagy]

On 05/11/2019 18:42, Joseph Myers wrote:
> On Tue, 5 Nov 2019, Szabolcs Nagy wrote:
>> 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 neither can declare unambiguously a single vector variant, only
>> a set of vector variants which may change in the future as new vector
>> architectures or vector call ABIs are introduced. So these mechanisms
>> are not suitable for libraries which must not declare more than what
>> they provide.
> 
> Rather, these mechanisms must imply a fixed set of variants defined at the 
> time the ABI was set, with any new variants added in future requiring some 
> different attribute / pragma to be specified, to avoid breaking existing 
> libraries and headers.  That's a requirement I made clear in the glibc 
> review of the original libmvec addition, and is why the x86_64 vector ABI 
> 
>  
> says "Compiler implementations must not generate calls to version of other 
> ISAs unless some non-standard pragma or clause is used to declare those 
> other versions are available.".

OK i guess similar text can be added to the aarch64 vector abi document,
so the meaning of omp declare simd is stable.

And then we only need the proposed mechanism to be able to specify a
smaller set of variants, or for future vector ABIs.

Re: [RFC PATCH] Extend the simd function attribute

[Joseph Myers]

On Tue, 5 Nov 2019, Szabolcs Nagy wrote:

> 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 neither can declare unambiguously a single vector variant, only
> a set of vector variants which may change in the future as new vector
> architectures or vector call ABIs are introduced. So these mechanisms
> are not suitable for libraries which must not declare more than what
> they provide.

Rather, these mechanisms must imply a fixed set of variants defined at the 
time the ABI was set, with any new variants added in future requiring some 
different attribute / pragma to be specified, to avoid breaking existing 
libraries and headers.  That's a requirement I made clear in the glibc 
review of the original libmvec addition, and is why the x86_64 vector ABI 

 
says "Compiler implementations must not generate calls to version of other 
ISAs unless some non-standard pragma or clause is used to declare those 
other versions are available.".

-- 
Joseph S. Myers
jos...@codesourcery.com