This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Aarch64] libmvec development status
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: "Sekhar, Ashwin" <Ashwin dot Sekhar at cavium dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>, "marcus dot shawcroft at linaro dot org" <marcus dot shawcroft at linaro dot org>
- Date: Thu, 16 Mar 2017 11:24:57 -0700
- Subject: Re: [Aarch64] libmvec development status
- Authentication-results: sourceware.org; auth=none
- References: <BY2PR07MB2421366D8C73A43DB61C707E92260@BY2PR07MB2421.namprd07.prod.outlook.com> <58CA8D02.208@arm.com>
On Thu, Mar 16, 2017 at 6:02 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> On 16/03/17 06:29, Sekhar, Ashwin wrote:
>> Hi Glibc Team, Aarch64 Maintainers,
>>
>> Could you please let us know what is the status of libmvec development for Aarch64?
>>
>> Saw in this linaro talk (https://www.youtube.com/watch?v=QBOOrJnqo9A) that ARM is actively working on this. Would appreciate if you could throw some light on when we can expect this to be upstreamed.
>>
>
> gcc-7 (in stage 4) won't have the necessary support for aarch64
> libmvec so it's hard to justify the urgency, i.e. upstreaming
> most likely won't happen in this glibc release cycle.
> (some discussions can start earlier though.)
The main justification is that Ashwin is working on the libmvec too.
He has proposed the ABI:
https://gcc.gnu.org/ml/gcc/2017-03/msg00077.html
Basically I would like this collaboration upstream rather than in the
private and not on the mailing list. Also delaying upstreaming the
base support means there will be two versions out there in the wild
starting soon. This is not a good thing.
>
>> Also, would appreciate if you could upstream a base code for aarch64 libmvec (need not contain any API implementations) so that it would enable others to work on target specific implementations. Would like to know your comments on the feasibility of this request.
>>
>
> i'm not sure what target specific implementation means in this
> context: i expected at most two sets of math functions for the
> two aarch64 simd variants (advsimd and sve).
I think he means core specific versions. For an example it might make
sense to have a different version that is specific to ThunderX2
CN99xx. There are some specific instructions sequences are faster to
do on cn99xx compared to other cores.
Thanks,
Andrew
>