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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3427 invoked from network); 5 Sep 2022 09:09:19 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 Sep 2022 09:09:19 -0000 Received: (qmail 11889 invoked by uid 550); 5 Sep 2022 09:09:16 -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 11857 invoked from network); 5 Sep 2022 09:09:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:message-id:from:to:cc:in-reply-to:subject: references; bh=3vbFHLg/9RY2W34aCxoyImIERTvYxbFspGzWG1M1z4U=; b=WxurgN3t8W4LgGiut8n0tOXWLTiJ8n5TGoDp8TwAxTo9cA7A35gCCOa+ h06zqSxnH3Ub9rhMxLXCpkvD9vUDtNuUaB4AAAcVPR4ujX2TlnFrXz4O0 G8WQ08HAh2pE57TvyJ8gLJwnUy25ArXLlbh+c6AjzFoFny1nWj0zcsP9e A=; Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=Paul.Zimmermann@inria.fr; spf=None smtp.helo=postmaster@tomate Received-SPF: SoftFail (mail3-relais-sop.national.inria.fr: domain of Paul.Zimmermann@inria.fr is inclined to not designate 152.81.10.51 as permitted sender) identity=mailfrom; client-ip=152.81.10.51; receiver=mail3-relais-sop.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="Paul.Zimmermann@inria.fr"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:192.134.164.0/24 mx ~all" Received-SPF: None (mail3-relais-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@tomate) identity=helo; client-ip=152.81.10.51; receiver=mail3-relais-sop.national.inria.fr; envelope-from="Paul.Zimmermann@inria.fr"; x-sender="postmaster@tomate"; x-conformance=spf_only X-IronPort-AV: E=Sophos;i="5.93,290,1654552800"; d="scan'208";a="22854534" Date: Mon, 05 Sep 2022 11:09:04 +0200 Message-Id: From: Paul Zimmermann To: Rich Felker Cc: musl@lists.openwall.com In-Reply-To: <20220902121755.GS7074@brightrain.aerifal.cx> (message from Rich Felker on Fri, 2 Sep 2022 08:17:56 -0400) References: <20220902121755.GS7074@brightrain.aerifal.cx> Subject: [musl] 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