This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/4 v2] Optimized generic expf and exp2f with wrappers
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: nd at arm dot com, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 14 Sep 2017 13:04:04 +0100
- Subject: Re: [PATCH 1/4 v2] Optimized generic expf and exp2f with wrappers
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <59B90BDF.7000503@arm.com> <59B90C2E.9050806@arm.com> <alpine.DEB.2.20.1709132012260.28319@digraph.polyomino.org.uk> <59BA4E34.2050902@arm.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 14/09/17 10:39, Szabolcs Nagy wrote:
> On 13/09/17 21:13, Joseph Myers wrote:
>> On Wed, 13 Sep 2017, Szabolcs Nagy wrote:
>>
>>> - disable math_errf.c and e_exp2f_data.c on i386 and ia64.
>>
>> sysdeps/m68k/m680x0/fpu has its own e_expf.c and e_exp2f.c, I would expect
>> those new files to be disabled there as well.
>>
>
> yes i made a number of mistakes:
> - m68k/m680x0/fpu does not need the math_errf/e_exp2f_data code
> - powerpc64/fpu/multiarch/e_expf-ppc64.c needs to suppress
> libm_hidden_proto too now that it overrides __expf
> (otherwise there is a hidden proto of __ieee754_expf_ppc64)
> - sysdeps/*/w_expf.c does not work to include srcdir/math/w_expf.c
> because the generated builddir/math/w_expf.c gets included.
> (i'm not yet sure what the right fix for this is, i can just
> copy the math/w_expf.c code around instead of including it
> or use a file name that does not collide with the generated files)
i guess i can just do
#include <sysdeps/../math/w_expf.c>
to make it clear that i want the file from the srcdir
> - the new versioned symbols are missing on ia64 too because
> it uses its own w_expf wrappers.
i will try to add .symver directives to the ia64
asm files in some ways.
but overall the symbol version fixes need a lot of
changes.. do we really need to carry asm math code
for barely supported targets? do ppl really care
if m68k/ia64/i386 get suboptimal math code?