This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3 1/9] Add new exp and exp2 implementations
- 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: Tue, 3 Jul 2018 18:40:27 +0100
- Subject: Re: [PATCH v3 1/9] Add new exp and exp2 implementations
- References: <40ebce63-b14f-1869-2e9c-32ef129d54da@arm.com> <alpine.DEB.2.20.1807022124500.3430@digraph.polyomino.org.uk>
On 02/07/18 22:43, Joseph Myers wrote:
On Fri, 29 Jun 2018, Szabolcs Nagy wrote:
There are sufficiently many different cases in the code (fma or not (maybe
that one's more of an issue for some of the other patches),
TOINT_INTRINSICS, EXP_USE_TOINT_NARROW, different values of EXP_POLY_ORDER
and EXP_TABLE_BITS and EXP_POLY_WIDE) that I think clear information is
needed about how those different cases have been tested and what purpose
they all serve. My starting expectation is that there should be one value
of EXP_POLY_ORDER and one value of EXP_TABLE_BITS in glibc (and probably
likewise for some other macros), without multiple alternative code choices
in glibc (possibly with #error in appropriate cases to make clear they
aren't supported in glibc), unless there is some reason different choices
are appropriate for different architectures - there should not be lots of
different cases in code and tables of data that are not actually used in
any glibc configuration.
ok i'll remove the unused variants.
they are there in case the tradeoffs i selected are deemed inappropriate
for some reason, but there is not much gain configuring these so i think
i should just drop the unused variants.. i'll keep separate code paths
for __FP_FAST_FMA and TOINT_INTRINSICS though.