From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7721 invoked from network); 4 Jan 2022 02:29:21 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Jan 2022 02:29:21 -0000 Received: (qmail 6100 invoked by uid 550); 4 Jan 2022 02:29:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 6068 invoked from network); 4 Jan 2022 02:29:18 -0000 Date: Mon, 3 Jan 2022 21:29:05 -0500 From: Rich Felker To: Paul Zimmermann Cc: musl@lists.openwall.com, sibid@uvic.ca, christoph.lauter@christoph-lauter.org, Jean-Michel.Muller@ENS-LYON.FR Message-ID: <20220104022905.GB7074@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] correctly rounded mathematical functions On Mon, Jan 03, 2022 at 02:07:59PM +0100, Paul Zimmermann wrote: > Dear Musl developers, > > the current C working draft [1, p392] has reserved names for correctly > rounded functions (cr_exp, cr_log, cr_sin, ...). > > We propose to provide such correctly rounded implementations > for the three IEEE formats (binary32, binary64, binary128) and the > "extended double" format (long double on x86_64). > > These implementations will be correctly rounded for all rounding modes, > for example one could do the following to emulate interval arithmetic: > > fesetround (FE_DOWNWARD); > y_lo = cr_exp (x_lo); > fesetround (FE_UPWARD); > y_hi = cr_exp (x_hi); > > Users who want a fast implementation will call the exp/log/sin/... functions, > users who want a correctly rounded function and thus reproducible results > (whatever the hardware, compiler or operating system) will use the > cr_exp/cr_log/cr_sin/... functions. Our goal is nevertheless to get the > best performance possible. > > Our objective is to provide open-source implementations that can be integrated > in the major mathematical libraries (GNU libc, Intel Math Library, AMD Libm, > Redhat Newlib, OpenLibm, Musl, llvm-libc, CUDA, ROCm). > > Are developers of Musl interested by such functions? > If so, we could discuss what would be the requirements for integration in > Musl in terms of license, table size, allowed operations. License: should be licensed under something permissive and MIT-compatible, preferably explicitly MIT if you'll be dual-/multi-licensing anyway. Table size: main consideration is that tables need to be pure shareable rodata, so no runtime generation of contents or pointers in contents. Failure to follow this would produce significant cost in *all processes* even ones that don't use the cr_* functions. I would hope they'd also fit in a few tens of kB of rodata, but I don't know how realistic that is. Allowed operations: I'm not sure what the scope of this question is. Are you asking if things like changing rounding mode would be okay? Or something else. musl implements C11 and hopefully future versions of the language library, but is implemented in C99 (+ very minimal set of common/"GNU C" extensions), so code to be included in musl shouldn't depend on new language features or compiler extensions not already used (at least without checking on them first). We also have softfloat-only targets and targets with excess precision, so code should be compatible with those (which means not depending on changing fenv; see commit 4f3d346bffdf9ed2b1803653643dc31242490944 for an example of where this came up). > We have started to work on two functions (cbrt and acos), for which we > provide presumably correctly rounded implementations (up to the knowledge > of hard-to-round cases) [2]. > > Christoph Lauter > Jean-Michel Muller > Alexei Sibidanov > Paul Zimmermann > > [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf > [2] https://homepages.loria.fr/PZimmermann/CORE-MATH/ Is there a standalone version of the code where it can be read in full not as a patch to glibc? Is the code being developed in such a way that it's not potentially a derivative work of the glibc versions? Rich