From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id A8DBF3858D3C for ; Mon, 24 Jan 2022 22:10:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A8DBF3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: cYwnCHadYyyw93X5bPpsJIEXCkiGJpuBza2KwNKMwoeYELSHbxofA9jZ2THaSzolegvPOTj6bO K5crTADJsvZVpX1u3h+M7GU7VFel5iZd74aRjdtKU54C1a4yDpQTrgVguRyDx445cHXwx7RPeu Y9luHmSnfpUBTjNpNuZ/ZMUKOvTFCxdhZR+N8Cmyc8ZtaLwTFQG8xI3Dr+rigoCMHYrMPDkg8R RTCVRhgZExlvWqQcxYX2O40tURDNbkI5nXkKZEqGowxOAwQtOA1zZXRvUjSjHn+eEmitH0qiY5 VJu/6Hb00ZU75gUgP/lNVxO3 X-IronPort-AV: E=Sophos;i="5.88,313,1635235200"; d="scan'208";a="71003900" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 24 Jan 2022 14:10:41 -0800 IronPort-SDR: 6byAPW0QL7rqc9FvMnhje8fPU6eLTBxCSZHCFjMYcXVnHnKjtNPXKSJp245SpVjahprjjJ2q5k EORsMrgqrhTIuw47LLVhC/7xC4bzgRIdnnt7b/zVU9PEDMKXshhVEV3mUW7aW2gC3fNG5FCEfC IEnZ53MzZNSY6qcLQD1qbR9hiv7nZUqu3vR4VDaVA0KbiapKFB7pCS72r92BB5bK08R1h052WS gwVoLhejRlpkoe97UHGvYqLoBCnCOUbk16I18XTpG0EXGzmnhonAqKjNSLyC8OuJtR+mC32jRq Grs= Date: Mon, 24 Jan 2022 22:10:34 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: CC: libc-alpha Subject: Re: Monday Patch Queue Review update (2022-01-17) In-Reply-To: <862a3190-a5e2-d44c-09d4-77673b4793ba@redhat.com> Message-ID: References: <862a3190-a5e2-d44c-09d4-77673b4793ba@redhat.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3115.3 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no 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: Mon, 24 Jan 2022 22:10:43 -0000 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. * 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.) * 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). * 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. * 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. -- Joseph S. Myers joseph@codesourcery.com