This is the mail archive of the
mailing list for the glibc project.
Considerations for libdfp integration
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Wed, 18 Sep 2019 00:26:56 +0000
- Subject: Considerations for libdfp integration
- Ironport-sdr: G3Hm9qhczJ6lpz3wPrL/0xY+RMI7PJG92WVLWTUidTMwHgnmOJN2Q8JXxftqtG25bZjnLm9E2a PDUNyodTycD67ylKx4P2gJOnXGX3v5VtNMwoeAvKLOhf9ig/XRGf2+vV3VEgdSNEPdUYyCsxnI sukvh1MpDa5k3TB171TrEDrKxpO/Y2fxxVoTTlDf0H1r+6f7Mj/GA2pISDk3Z6721JXZihGASy CkU51zdv/EbH2RPIacxyzOP9HfEe9tpGHtyKQzbwNlEWv3AWxQjifxSF7wr4lmpy8mWAeOTvr9 /gQ=
- Ironport-sdr: JMdVerf9R0NTrsoS/hd/ndCh5ibyQE/SAmyQtMAhR52O43LDa0fCsquPMZ31Pb/F3FxjFi2tsg 0efE7B5iCtNNtzSB/vM8AMG088kxOztuWBVJdOBbRYmUXsjP2jowQ0+5Pw4iIxc5rx2+kOvUO6 lKHBudJhdm900IdsQmo76ai0YCd2ALK5iQraxNFUey41lOtf1P84dwICvcOjDLiodWHnU+m0Hr WNLxbc3KgkFkktX9YWhrMoannUNxEbjNzJt10k7GYrt0jtXR76D9mgbSsWr9OR3WvrMEQDO4np WhY=
There was some discussion at the Cauldron about the possibility of
integrating libdfp into the glibc sources, in view of decimal floating
point being an optional feature in the C2x draft standard (rather than a
separate TS as previously).
We'd need to consider this carefully to decide whether we want to include
it in glibc or not. *If* we do, the following are some technical
considerations regarding what I think such an integration should look like
(since the natural way to do various things as part of glibc differs from
the natural way to do them as a separate project). Exactly what would be
required for integrating libdfp functionality, versus being possible
future projects, would of course be subject to discussion (as would other
considerations such as future maintenance of the DFP code if included in
glibc, and under what circumstances DFP versions of new libm functions are
expected to be added alongside the binary FP versions).
1. Should the code go in separate shared libraries, or in the libc.so and
libm.so shared libraries?
If in separate libraries, I think they should be referenced by AS_NEEDED
in .so (and .a) linker scripts, so no special -l options would be needed
to find these functions.
An argument against separate libraries is the general move in glibc
towards not having so many separate shared libraries. Arguments for
having separate libraries include not putting large amounts of rarely-used
code in libraries that most or all binaries load; see Jakub's objections
to having the DFP code in shared libgcc
<https://gcc.gnu.org/ml/gcc-patches/2009-07/msg00339.html>. I should note
that it's certainly not necessary to have 2 MB of data to do DFP binary /
decimal conversions; they should be doable with a few kB of data, possibly
with a speed/space trade-off (I don't know how well optimized the libbid
code in libgcc is anyway).
Furthermore, with separate libraries there is the possibility that
building those libraries could be optional. In particular, if an
architecture gains DFP support in a future release of GCC, it would, as
with libmvec, be possible to support building those libraries in glibc
with a newer GCC version without making that version a requirement for
building glibc on that architecture. (A DFP support patch for AArch64 was
posted in July 2017
<https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00788.html> though nothing
much happened with it. The RISC-V architecture reserves the name 'L' for
a standard extension for DFP support, though I see no sign of anyone
having attempted to design such an extension. I don't know about any DFP
interest for other architectures currently lacking support.)
2. Some functionality would, however, need to go directly in libc / libm,
which might complicate making support optional.
In particular, the support for DFP printf / scanf formats, and the support
for the DFP rounding mode (which is separate from the rounding mode for
binary floating point, and needs to be part of fenv_t as handled by the
existing fenv_t functions, whether it's a hardware rounding mode or a TLS
3. Where libdfp uses its own headers to declare DFP functions, naturally
an integration with glibc would put declarations, with appropriate
conditionals, directly in the existing glibc headers (so e.g.
bits/mathcalls.h would get included for DFP types and have conditionals
for whether particular functions are available for such types).
4. I expect glibc should only support, for each architecture, the default
choice between DPD and BID format, and not support GCC configured with a
non-default --enable-decimal-float=<format> option. That is, the format
supported would be BID format for x86_64 / x86 and DPD format for powerpc
5. At present, the libgcc functions for DFP (i.e. functions for which GCC
generates calls implicitly for arithmetic operations) exist both in static
libgcc and in libdfp.
As I understand it, the libgcc copies don't have full rounding mode /
exceptions support, while the libdfp copies do (complete with the DFP
rounding mode as a TLS variable when hardware DFP support is not
Having separate copies, one with rounding mode support and one without, is
unhelpful to users; it means that which copy they get depends on the exact
options / option ordering passed to the linker. That problem was
addressed for powerpc soft-float (where binary floating point had a
similar issue) by making the libgcc copy of these into compat symbols
(thus not available in static libgcc) when GCC is configured with new
enough glibc. So if we integrate these functions into glibc I'd expect
them to be disabled in libgcc when GCC is configured with new enough
glibc, so only the glibc (whatever shared library) copy would be used in
6. Tests for DFP versions of libm functions ought to be integrated into
the gen-auto-libm-tests infrastructure for generating expected results, so
using all the existing test inputs which cover many difficult cases for
various functions. The existing libdfp tests are much more limited and
having two different systems for such tests would be unhelpful.
That would however be a large and complicated project. Neither decNumber
nor mpdecimal supports most of the libm functions, and some of those they
do support are explicitly documented as not correctly rounding. I think
it would probably be best to have a correctly-rounding implementation
based around converting DFP inputs to binary, using MPFR and doing
appropriate interval arithmetic to ensure the correctly rounded DFP result
can be deduced uniquely from the MPFR results, but while that's much
simpler than reimplementing all the correctly-rounding arbitrary-precision
functions from scratch for DFP, it's still a substantial amount of work.
DFP tests also need to deal with functions required to produce results
with a given quantum exponent, an issue that does not arise for binary
Joseph S. Myers