From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id E49043858030 for ; Tue, 25 Jan 2022 09:27:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E49043858030 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=inria.fr 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=ZR2lpZGbOZ3St04jxo5xKthk6ccbuoifRk/R7eUY7bc=; b=ak7nUgx2KLhERNNsrVMqVTUxAztUOqj31D3qjDy4kqTCxHmTX4VKGU5E ewzKcEoaQopP/zCagXQ0O9+NhybuOXsdXOCv5yb8Aj3RkrwcJmQk4hxVX L4Nw2XJZY/dTQyFnOJwI8idgK4iPvianQ7UM8VSJrKB5OZTCFSmUay3dW I=; X-IronPort-AV: E=Sophos;i="5.88,314,1635199200"; d="scan'208";a="3998643" Received: from tomate.loria.fr (HELO tomate) ([152.81.10.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jan 2022 10:27:12 +0100 Date: Tue, 25 Jan 2022 10:27:11 +0100 Message-Id: From: Paul Zimmermann To: Joseph Myers Cc: libc-alpha@sourceware.org, sibid@uvic.ca, stephane.glondu@inria.fr In-Reply-To: (message from Joseph Myers on Mon, 24 Jan 2022 22:10:34 +0000) Subject: Re: Monday Patch Queue Review update (2022-01-17) References: <862a3190-a5e2-d44c-09d4-77673b4793ba@redhat.com> X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 09:27:15 -0000 Dear Joseph, thank you very much for your feedback, this is extremely useful! > Date: Mon, 24 Jan 2022 22:10:34 +0000 > From: Joseph Myers > > On Tue, 18 Jan 2022, Carlos O'Donell via Libc-alpha wrote: > > > * we are making good progress in the CORE-MATH project: 17 out of 26 > > functions are now available in single precision (binary32). > > See https://homepages.loria.fr/PZimmermann/CORE-MATH/. > > In most cases the correctly-rounded CORE-MATH code outperforms the > > GNU libc one (see the "perf" graphs). The only exceptions so far are > > the cosf function on i7, and the expf function. > > A few comments based on spot checks of the functions there: > > * Many of the functions are severely lacking in comments, I'd expect > detailed comments throughout the functions explaining what is going on. we'll try to add more comments > * Many of the functions seem specific to 64-bit systems, with e.g. > > typedef union {double f; unsigned long u;} b64u64_u; > > making an assumption on the size of long. You should use standard types > from such as uint32_t and uint64_t throughout whenever you need > a given integer width, which probably means avoiding "long" everywhere. > (Likewise, avoid local typedef names such as u64.) indeed, uint64_t would be better than "unsigned long" in this example > * Use of __int128 (e.g. in cosf) is also specific to 64-bit systems; GCC > doesn't support it on 32-bit systems. Code needs to be written so as to > work on 32-bit systems as well as 64-bit (if that means different code > paths, you should probably replicate the testing for being correctly > rounded on both 32-bit and 64-bit systems, as well as for other variations > such as architectures where GCC fuses multiply and add into fma unless you > use -ffp-contract=off). indeed, we will probably also provide code running on 32-bit systems. > * Correct underflow, overflow and inexact exceptions are required for > cr_*; it would be a good idea to check for that in your exhaustive > binary32 testing (and fix the implementations accordingly) - though > covering both before-rounding and after-rounding tininess detection cases, > for functions where some inputs give results in the relevant narrow > intervals for which those are different, would require testing on multiple > architectures, and in practice it might be easier for us to make sure to > add all such inputs to the glibc testsuite and test any proposed > integration on such architectures. we are aware of this > * I'm not sure what the coding style in these functions is meant to be, > but given e.g. all the other functions in the files not suitable for > inclusion in glibc as-is my assumption is we'd want to reformat anything > included in glibc into GNU style. clearly the code we propose will need to be reformated by the developers of the different math libraries with their respective coding style. Best regards, Paul PS: the CORE-MATH page moved to https://core-math.gitlabpages.inria.fr/