Martin Liška <mli...@suse.cz> writes:
> On 2/20/19 11:04 AM, Richard Sandiford wrote:
>> Martin Liška <mli...@suse.cz> writes:
>>> On 2/19/19 11:32 PM, Steve Ellcey wrote:
>>>> I am not sure if we
>>>> need all of those but it seemed better to have them and not use them
>>>> than to find out we need them later.
>>>
>>> Hi.
>>>
>>> About the SVE: isn't the ABI dependent on the bit width of vectors?
>>
>> It's dependent on the types. There are ABI types for Advanced SIMD
>> vectors and ABI types for SVE vectors. The two end up being the same
>> length at runtime on when the SVE vector length is 128 bits, but they're
>> still separate types with separate conventions.
>>
>> (E.g. __attribute__((vector_size)) never creates an ABI-level SVE vector,
>> even with -msve-vector-bits=N, but it can create an ABI-level Advanced
>> SIMD vector.)
>>
>> I think we should leave the SVE stuff out for now though. ISTM that:
>>
>> !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64')
>> !GCC$ builtin (sin) attributes simd (notinbranch) if('aarch64_sve')
>>
>> is trying to say that there's both an Advanced SIMD implementation of sin
>> and an SVE implementation of sin. But AFAICT the patch would just treat
>> the two the same way when SVE is enabled, which I think in practice means
>> that both would declare an Advanced SIMD function.
>>
>> Once we support SVE vector functions, how would the header file declare
>> the Advanced SIMD function when SVE is enabled on the command line?
>> Or similarly for other architectures with multiple vector ISAs?
>> For C I think this would be done with #pragma GCC target push/pop.
>
> I guess that should be handled internally in glibc via e.g. ifunc mechanism.
> Glibc ABI for SIMD functions should follow normal calling conventions.
The vector architecture determines the function interface though.
It's part of the mangling scheme and decides the types of the vector
parameters and results. E.g. Advanced SIMD vector sin and SVE vector
sin have different (public) names and different interfaces.
So at least in C, "#pragma omp declare simd" doesn't just say that a
vector version exists, it says that a vector version exists for a specific
architecture.
> > Is there any significance to the names of the multilibs? E.g. are we
> > supposed to follow Debian conventions?
>
> No, consensus about the names would be only only shared in between a compiler
> and a C library.
OK, great.
Thanks,
Richard
