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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14126 invoked from network); 27 Dec 2021 17:27:42 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Dec 2021 17:27:42 -0000 Received: (qmail 21668 invoked by uid 550); 27 Dec 2021 17:27:40 -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 21627 invoked from network); 27 Dec 2021 17:27:39 -0000 Resent-From: Rich Felker Resent-Date: Mon, 27 Dec 2021 12:27:27 -0500 Resent-Message-ID: <20211227172727.GX7074@brightrain.aerifal.cx> Resent-To: musl@lists.openwall.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1640622461; bh=XQJ5Tf3sy7q8R4nz524pbTnBg1Q+O6M56PyFxjWT3xQ=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=HmTXgKqDUZSPBzkgur1j3OcnUDwGQ4ZFTRm7tKPGbXtILkWFTEsTVMh+f2VUhhYOI 4lvDupprX6Ul3aMY+78h4tTXTC6LvgAyU5VzSmNM9AeGNN3hJbrl+NnwllMnsS9k7K YxNbPQiI0ucD4fikgxZFSAakgoKZpM+hEkkjvz9k= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Mon, 27 Dec 2021 17:27:38 +0100 From: Markus Wichmann To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20211227162738.GD1949@voyager> References: <20211226204238.GA1949@voyager> <20211227150010.GU7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211227150010.GU7074@brightrain.aerifal.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:KoYJMkTPxM5yNSUmgEdOEhAFhuppWOlenN9t0ETTSN2fmwnhmfz +F3LCWNcVamV07+SonUo38x9vHB0mrH8PXQGjXVcAr5PYxU79P3bWSJcrzyGp+V9hkLENIZ gAA5jRdovKlv35fQu8vLEHCyT4Z9hWzB6MNmU8l9GeQ6MBSVIO0X2tr+vPqQkWH0EztFJQw 8nTD2rfL8uA89E+WKoODQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:OjSBqVYuO+U=:TN26j564m7wIjQh0XWi+cN MRMCzlvQMjZum+tzGPYzgZuXbvaXizGWMK0u4fEssXr+nUy9VXE+MTjbR4+WLBawKSaP9hEuT Yhtw7zwEL11trPdcw2g5G9uPQ8/574AkGokVr6IkUEMeWrfSmAb/y3puTEov6tC4pwcF2iPwv 4ynC2CDpfVNff5T0+ny4MWtg0nxFnKj8I8odw0tNMzaewc8PDeihuK15IyKHnG9BdKfasLW2x +ci/mZlFgAWa5HMswq1Y0x1NAw1/jjBTsZhRH0rE5zFVR4LV/sqvTataInXbcQeD9+HlGheWJ WsxDBnkFG8R7MGZqGDXeg4ApXr3lkUQLBnWCVFnMjDHxqPGFxx0Nez2sgmKBmBsjxzQNaiheQ 8Y37Y1F1bAKPQn5YmsvImDZQU1CYnU5q+ukAabLBLbJWHSq0mPdf1o2yiDDvMU9v7TcdfYKze 9H5SeotKdKGAu1HJVgP/SwMank+PMe8LjICr0gEHLCClMPsDdlhNs3ZabPhsuFa+8Cx1CvItu HqI97k1c1BYSo/0igeETs2knwH6jf+0QfpZ28hb3eEwgsi4e8yLFmuMGtuDUFtzJcF6LXVqIH KV+w6pkjeWefb/m8KGAA5mS0/v+oNstZE/TyXw9CJzjnLnLx4PtXfivJV/bYrKstIKhV+hS5F 7rI5Q1pYwP1paph+w+Idb7fpJr8I042VofbrSFbSWNMK8+U2T7cqnObgHz9CY7pJj2yOwx6ou 28wdGL0xk78nm9ay944WJoSWCpgl5GOh+G69wlhOBYeJLZ156885qG2cwe/7tNLcc8yWmoenZ L/A/3pDGKL64vmHjbD+z8/3X6Zdgg+kwi5+eWoUHTz4Lb4Iy+DLXMZeRWtitw6H4rg/Y6RP1L d8AsZOV7pLYBfJ13ZGEouP5hA2PbqlElitMD0Ist5x5W1Wh0DSIVOwSc24prbGiVE4ggxqw+u 36DYHb2wK1+bKXYsMKqlt0xEqjc2KmcyazN9uawWPuljb436PcdK5p/o+95ybyaqg5iTwKboh 1oHY3mgxJpXYI02W9YRkQEEKIAZhH4OQ2r166TAGWKXJXbljBf2lY5fvuDRWDW/kpQJrX+tRq FRuj//tgkma8ng= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] ASM-to-C conversion for i386 On Mon, Dec 27, 2021 at 10:00:11AM -0500, Rich Felker wrote: > On Sun, Dec 26, 2021 at 09:42:38PM +0100, Markus Wichmann wrote: > > For the maths code, > > One thing I found right away on the math code: You can't use "=3Dt" for > output in a float or double variable unless the asm naturally > guarantees there's no excess precision (e.g. fmod where the operation > is exact and the precision is necessarily bounded by the input > precision). Otherwise you need "=3Dt" to a temporary long double output > to then let the compiler convert down to float or double (e.g. at time > of return; I think we're still using explicit cast there too in case > some compilers get this wrong). > Oh yes, I noticed the missing conversion instructions in some places and didn't in others. As I said, some cleanup is in order. The branch is not currently ripe for merging (yet). The code was written over several days in various stages of alertness and distraction. > This was probably a compromise between the "likely" notation I don't > like (reads as a predicate lik "if this is likely" rather than "if X, > which is likely") and my rather odd suggestion of as_expected (if > (as_expected(x))). :-P > I agree to the point, although likely()/unlikely() seems to be the convention everywhere else. OK, so predict_X it is. Which is still in libm.h, so I cannot use it anywhere else in the code. > > Most of that code was straightforward, but some of the more complex > > functions I am not sure about. What is up with __exp2l()? I can see th= at > > expl() is calling it, but I'm not sure why. But its existence forced m= e > > to employ a technique not used elsewhere in the code (that I could > > find): A hidden alias. I vaguely recall that such hackery was rejected > > before (on grounds of old binutils reacting badly to such magic), but = I > > don't really know what else I could have done. Or was the correct way = to > > make __exp2l() a hidden function with the actual implementation and > > exp2l() (without the underscores) a weak alias? > > Here it doesn't really matter at all since they're both in the > baseline C namespace. > I found later that you introduced the hidden double-underscore versions of some symbols that are called directly from assembler elsewhere to get rid of things that would be textrels if not for a linker option. So that entire point is moot with the move to C, anyway. I'll remove those in the math code. In the string code, I have currently defined __memcpy_fwd this way. Not sure what to do there, yet, and the way I'm using the definition in memmove() might invoke undefined behavior, because of declaration/definition mismatch. Or do I define __memcpy_fwd without "restrict"? > So I think > having them all share an inline function is fine. Of course since > there's then no reason for them to be in the same source file, they > should probably be moved to their corresponding named files instead of > empty .c files. > So, you want me to move the core function to a header file as static inline? That is possible and avoids the source duplication problem. I was also wondering about those functions where the smaller-precision versions just do what the long-double version is doing with maybe some pre-/post-processing. Should they receive the same treatment or should they just call the long-double version? E.g. acos, asin, log2, &c. Not sure if the savings from not having to do a proper call/return are worth the hassle of a new file with some of these. > > Speaking of, how would you like those? One patch for everything, one > > patch per directory (i.e. one for thread, one for math, one for fenv, > > one for string), or one per functions group (the three precisions of > > each function), or one per function? I don't want to overwhelm you. > > Probably split up somewhat so that things that would need discussion > separately or that could be conceptually right/wrong independent of > one another (not just minor bugs) are separate commits. After looking > at the commits in your repo more I can probably make a better > recommendation. > OK, I'll use my judgment when the time comes. Ciao, Markus