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.
>
> 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.
Thanks,
Martin
>
> Thanks,
> Richard
>
