From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14989 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Stefan Kanthak" Newsgroups: gmane.linux.lib.musl.general Subject: Re: More patches for math subtree Date: Tue, 10 Dec 2019 22:32:26 +0100 Organization: Me, myself & IT Message-ID: References: <2C3325A208DA4260A1A0F7B4517D6DFA@H270> <20191210193558.GK1666@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="88607"; mail-complaints-to="usenet@blaine.gmane.org" Cc: To: "Rich Felker" Original-X-From: musl-return-15005-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 10 22:44:58 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1ienJR-000Mni-E3 for gllmg-musl@m.gmane.org; Tue, 10 Dec 2019 22:44:57 +0100 Original-Received: (qmail 19821 invoked by uid 550); 10 Dec 2019 21:44:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 19793 invoked from network); 10 Dec 2019 21:44:52 -0000 In-Reply-To: <20191210193558.GK1666@brightrain.aerifal.cx> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.24158 X-VADE-STATUS: LEGIT Xref: news.gmane.org gmane.linux.lib.musl.general:14989 Archived-At: "Rich Felker" wrote: > On Tue, Dec 10, 2019 at 05:57:55PM +0100, Stefan Kanthak wrote: >> Some more optimisations: the current implementations of ceil(), floor() >> and trunc() for i386 change the rounding control using fldcw instructions, >> which are SLOW; these patches provide faster and smaller branch-free (!) >> implementations. >> >> JFTR: I'm NOT subscribed to your mailing list, so CC: me in replies! >> >> --- -/src/math/i386/floor.s >> +++ +/src/math/i386/floor.s >> @@ -1,67 +1,26 @@ >> .global floorf >> .type floorf,@function >> floorf: >> flds 4(%esp) >> jmp 1f >> >> .global floorl >> .type floorl,@function >> floorl: >> fldt 4(%esp) >> jmp 1f >> >> .global floor >> .type floor,@function >> floor: >> fldl 4(%esp) >> +1: fld %st(0) >> + frndint >> + fxch %st(1) >> + fucomip %st(1),%st(0) >> + fld1 >> + fldz >> + fcmovb %st(1),%st(0) > ^^^^^^ > > fcmovb is not in the baseline ISA. This is but irrelevant or inconsequent: FCMOV* as well as FCOMI* and FUCOMI* were introduced with the PentiumPro. If you allow the use of the latter you can safely use the former too. And FCOMI* and FUCOMI* are already used in other .S files. > Otherwise, I *think* the idea of this patch looks good, provided I'm > not missing anything with respect to how status flags are affected. FRNDINT takes care of them! > As noted in the other email (sorry about not CC'ing you before; I've > got you on CC now), I really want to get rid of all these .s files in > favor of __asm__ statements with proper constraints in C source files. > That makes them inlineable with LTO, and makes it possible for the > compiler to select to use an instruction like fcmovb conditionally > based on the targeted ISA level rather than having to do a .S file > with hard-coded preprocessor conditionals. While this is generally good idea, there's no guarantee that a compiler will emit a branch-free instruction sequence like those shown above. I also doubt that a compiler will produce the 5 instruction sequence shown in my patch for src/math/i386/remquo.S which collects the FPU flags C0, C3 and C1 set by FPREM. I noticed that you provide .S files for "long double" on x86-64, but not for "double" and "float". I therefore assume that you use the SSE floating-point instructions there, respectively let the compiler use them. Does any compiler emit branch-free instruction sequences like the following for Intel CPUs without SSE4.1, i.e. without ROUNDSS/ROUNDSD? .code ; Intel syntax ceil proc public extern __real@8000000000000000:real8 movsd xmm1, __real@8000000000000000 extern __real@3ff0000000000000:real8 movsd xmm2, __real@3ff0000000000000 extern __real@4330000000000000:real8 movsd xmm3, __real@4330000000000000 movsd xmm4, xmm1 andnpd xmm1, xmm0 andpd xmm4, xmm0 cmpltsd xmm1, xmm3 andpd xmm1, xmm3 orpd xmm1, xmm4 movsd xmm3, xmm0 addsd xmm0, xmm1 subsd xmm0, xmm1 movsd xmm1, xmm0 cmpltsd xmm0, xmm3 andpd xmm0, xmm2 addsd xmm0, xmm1 orpd xmm0, xmm4 ret ceil endp Or instruction sequences like .code ; Intel syntax copysign proc public movd rcx, xmm0 movd rdx, xmm1 shld rcx, rdx, 1 ror rcx, 1 movd xmm0, rcx ret copysign endp .code ; Intel syntax fdim proc public movsd xmm2, xmm0 cmpsd xmm0, xmm1, 6 subsd xmm2, xmm1 andpd xmm0, xmm2 ret fdim endp > It also precludes x87 stack imbalance bugs like CVE-2019-14697, which > make me really wary of manual changes to these files. > > Would you be interested in working on converting over the files you > want to optimize (or even others too) to that form at the same time as > doing the optimizations? I don't use musl-libc; I also don't use an OS or a compiler/assembler which can be used to build it. I just stumbled upon the functions for which I sent in patches while searching for code which uses Intel's FPU. > It would really help with review process and with improving the overall > code state. If I start using musl-libc I'd be interested and rewrite these parts. regards Stefan