Considerations for libdfp integration

[Joseph Myers]

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/2008-08/msg00870.html> 
<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 
variable).


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 
/ s390.


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 
available).

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 
future.


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 
floating point.

-- 
Joseph S. Myers
joseph@codesourcery.com