Steve Ellcey <sell...@marvell.com> writes:
> On Wed, 2019-02-20 at 10:04 +0000, Richard Sandiford wrote:
>> (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.
>
> It looks like you are right. I did not know that GCC would essentially
> use the non-SVE vector functions to handle SVE vectors. So right now,
> GCC doesn't seem to need to differentiate between SVE and non-SVE.
>
>> Once we support SVE vector functions, how would the header file declare
>> the Advanced SIMD function when SVE is enabled on the command line?
>
> I guess this is what I was thinking the aarch64_sve if would be for,
> but there is a difference between supporting SVE (using non-SVE vector
> functions) and supporting SVE with functions that can take and return
> an SVE vector. I think that we should use 'if('aarch64_sve')' to mean
> SVE is enabled and we want GCC to call SVE vector functions. So right
> now this would always return false, until such time as GCC is changed
> to do calls with SVE vectors as arguments.
That isn't a global decision though. Whether we use SVE or not when
it's available depends on the context. The ideal would be to try
both SVE and Advanced SIMD and pick whichever gives the lowest cost.
(We're hoping to do that for GCC 10.)
The header file should just declare the functions that are available.
That includes declaring SVE versions even if SVE is currently disabled,
because SVE could be enabled later using target pragmas or target_clones
attributes (one we support those).
We might want a new syntax for this.
> Given that it would always return false I guess we could just drop it
> out for now.
Yeah, agreed.
> FYI: If anyone is interested here is a test program I was compiling to
> see what GCC does with SVE, I compiled with -march=armv8.5-a,
> -march=armv8.5-a+sve and -msve-vector-bits=[256,2048,scalable] to see
> what sort of code got generated. I was a little surprised that using
> -march=armv8.5-a (without the +sve) and -msve-vector-bits= did not give
> a warning. Why set sve-vector-bits if SVE is not enabled.
The idea was that -msve-vector-bits= would still affect any SVE-specific
code in a TU that contains both SVE and non-SVE code. E.g. if you use
target_clones (again once it's supported) to provide SVE and non-SVE
versions of a function, the -msve-vector-bits= would affect the SVE
version.
I'm torn about about whether we should proactively add the ILP32 and
big-endian conditions now or wait until there's a specific need.
Unless anyone strongly objects, let's keep them for now.
Thanks,
Richard
