From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id C7B791F463 for ; Wed, 18 Sep 2019 00:27:07 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:mime-version :content-type; q=dns; s=default; b=d6ECARF81E4sVPnip265AXY5WGVpA e4U/aHAnr5H6LYxPXnLalU3459K7nmPkral2aTdzeZ2hK73Ush+NUShRS7Y4nRWH xufNO4AxwrvLvSkW6gpHOPfERazFbFE0+9Dx7JRl+rHg+mMyMEySTcVdDYxZO40T Ffuf8OvS6TOGWc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:mime-version :content-type; s=default; bh=B1npys5/eyan8kWsMnqta8nqAD4=; b=Cy8 grqTMPgsHjeUdXESWfZfCWVfVS3QMZ9W2oJTu+8DQWp8fV4tHsN0/TCO5ldkxcn5 Sr/Tw1njy6AMwVxii3uzRf3HqzkDDUIxOMZ9RKSm0+Fe3Bw03Ep7EGQLRTxzXMSC 2xWj3qm+bK58fYEF3VFWzv1NkGrClf14SmGSEuPM= Received: (qmail 43115 invoked by alias); 18 Sep 2019 00:27:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 43105 invoked by uid 89); 18 Sep 2019 00:27:05 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: esa4.mentor.iphmx.com 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= Date: Wed, 18 Sep 2019 00:26:56 +0000 From: Joseph Myers To: Subject: Considerations for libdfp integration Message-ID: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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 . 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 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= 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