Re: [musl] Re: integration of CORE-MATH routines into Musl?

[enh <enh@google.com>]

[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]

On Mon, Sep 5, 2022 at 2:09 AM Paul Zimmermann <Paul.Zimmermann@inria.fr>
wrote:

>        Dear Rich,
>
> > 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.
>
> the current situation is:
>
> - IEEE 754 does not require correct rounding for mathematical functions
>
> - indeed, the C2X standard will reserve cr_xxx names for correctly rounded
>   functions
>
> - thus mathematical libraries will have essentially 3 choices:
>
> 0) either provide incorrectly rounded functions as (say) exp.
>    This is the current situation.
>
> 1) provide incorrectly rounded functions as exp, and correctly rounded
>    functions as cr_exp.
>
> 2) or provide only exp, with correct rounding (then cr_exp could be an
> alias
>    for exp)
>
> It seems that LLVM-libc will go for 2), I have no news from other
> libraries.
>

(fwiw, #2 is almost certainly what we'll do with bionic too.)


> > 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.
>
> If you look at Table II from https://hal.inria.fr/hal-03721525, you see
> that
> for *single* precision functions (binary32), indeed that's all-wins.
>
> Best regards,
> Paul
>
>

[-- Attachment #2: Type: text/html, Size: 2580 bytes --]