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.
Is there any significance to the names of the multilibs? E.g. are we
supposed to follow Debian conventions?
Thanks,
Richard
