On Fri, Sep 02, 2022 at 12:10:18PM +0200, Paul Zimmermann wrote:
> Dear Rich,
>
> we now distribute the CORE-MATH routines under the MIT license,
> to ease integration into Musl (among other libraries).
>
> Please can you point out to a Musl developer who might be
> interested to integrate some CORE-MATH routines?
>
> We will try to answer potential issues that might arise
> during this integration.
>
> Best regards,
> Paul
>
> PS: see https://hal.inria.fr/hal-03721525 for more details about
> the CORE-MATH project.
Could you summaraize briefly what you have in mind, and what tradeoffs
might be? Are these intended to be drop-in replacements for the
existing standard functions, or implementations for the "cr" versions
thereof? I have not followed closely the "mandatory requirement of
correct rounding for mathematical functions in the next revision of
the IEEE-754 standard" topic and how it relates to the future of C,
but my vague recollection was that the direction folks were leaning
was towards a separate set of cr*() functions or something. But if
it's possible to do correct rounding in a way that's all-wins
(performance, size, quality of results) or nearly all wins (maybe
slightly larger?), at least for select functions, that seems very
interesting.
"what he said" (including the "i haven't been following the details").
assuming you have good answers to those questions then -- if you haven't already done so -- you should probably also bring this up with freebsd-numerics (
https://wiki.freebsd.org/Numerics and the mailing list mentioned on that page). that's the source of the vast majority of the libm code used by Android/iOS/macOS. (the exceptions for Android are mostly binary128 stuff from netbsd and arm32/arm64 optimized code from
https://github.com/ARM-software/optimized-routines.)
on the opposite end of the spectrum, llvm-libc isn't widely used at all, but that work is at such an early stage (although it seems like they have had a heavy libm focus) that they probably don't have existing implementations for a lot of stuff.
it seems -- having admittedly not read past the abstract of the paper that you linked to -- that you're only addressing binary32 so far? not even binary64? (i'm used to binary128 not getting much love!)
(oh, and thanks for picking a license that makes it much more likely that all the libcs can use your work!)
Rich