This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: Add a POWER8-optimized version of powf()
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: "munroesj at linux dot vnet dot ibm dot com" <munroesj at linux dot vnet dot ibm dot com>, "adhemerval dot zanella at linaro dot org" <adhemerval dot zanella at linaro dot org>, "pc at us dot ibm dot com" <pc at us dot ibm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Fri, 2 Jun 2017 16:06:23 +0000
- Subject: Re: [PATCH] powerpc: Add a POWER8-optimized version of powf()
- Authentication-results: sourceware.org; auth=none
- Authentication-results: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <AM5PR0802MB2610870578CCA938957DAACC83FD0@AM5PR0802MB2610.eurprd08.prod.outlook.com>,<0f81b30e-b8c9-60e9-4fa3-3528ad21e0d7@us.ibm.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Paul Clarke wrote:
On 05/27/2017 07:55 AM, Wilco Dijkstra wrote:
> I'm not easily able to test and validate performance on other platforms.
> I'm not sure the maintainers of those other platforms would want me to, anyway.
>
> I do understand the motivation to encourage architecture-agnostic code in lieu of architecture-specific.
>
> How about making it fairly trivial to share the code, by dropping it in a common place,
> like /sysdeps/generic or /sysdeps/wordsize-64 or /sysdeps/ieee754? Other arches
> can then easily include it without having to copy it or include it from a foreign arch directory, when and if they wish.
>
> This seems like an issue that would be commonly encountered. Are there generally recommended practices?
Not as far as I know. The current math code is a mess due to all the different directories,
the odd wrappers, the headers that can bypass the wrappers and on top of that the ifuncs...
So we will need to simplify all this, starting with removing the wrappers.
>> As it happens Szabolcs wrote a prototype powf that is not only
>> more accurate but also 4x faster, all using generic code. With these gains, target
>> specific math functions will be obsolete...
>
> Is that forthcoming?
Yes - after they are published under a less restrictive license. In GLIBC we'll need to agree
on how to deal with the wrappers and establish a good place to add new math functions.
Wilco