|
Message-Id: <mw5yi2chn3.fsf@tomate.loria.fr> Date: Mon, 05 Sep 2022 11:09:04 +0200 From: Paul Zimmermann <Paul.Zimmermann@...ia.fr> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: integration of CORE-MATH routines into Musl? 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. > 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.