From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13892 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: FE Exception triggered by comparison Date: Wed, 27 Feb 2019 12:26:41 -0500 Message-ID: <20190227172641.GW23599@brightrain.aerifal.cx> References: <20190225155109.GB28106@voyager> <20190227164225.GV23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="266620"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13908-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 27 18:26:57 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 1gz2yu-0017Hn-NQ for gllmg-musl@m.gmane.org; Wed, 27 Feb 2019 18:26:56 +0100 Original-Received: (qmail 29938 invoked by uid 550); 27 Feb 2019 17:26:54 -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 29919 invoked from network); 27 Feb 2019 17:26:53 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13892 Archived-At: On Wed, Feb 27, 2019 at 08:14:07PM +0300, Alexander Monakov wrote: > > > On Wed, 27 Feb 2019, Rich Felker wrote: > > > Are there reasons we should perhaps use the __builtin versions of > > these when __GNUC__ indicates they're available? I like our bit test > > versions we have now, and I think they're sufficiently efficient, but > > I'm open to changes if there's a good reason. > > Well, it really depends on what one considers 'sufficiently efficient'. > Instead of comparing a register with itself and testing flags (2 instructions) > you get (for 'int f(double x){return isnan(x);}'): > > f: > movabsq $9223372036854775807, %rdx > movq %xmm0, %rax > andq %rdx, %rax > movabsq $9218868437227405312, %rdx > cmpq %rdx, %rax > seta %al > movzbl %al, %eax > ret > > (note that movq %xmm0, %rax is going to be more costly than a normal > move as it crosses from fp to integer domain in the cpu) > > I think musl bit test can be implemented more efficiently via right-shifting > the representation in %rax first, avoiding 64-bit immediates, Or left-shifting rather than masking to get rid of the sign bit? That's all it's doing. I don't think right-shift is okay since losing any low bits would break the comparison. > but even then > I'd say the "native" version is preferable. I suspect this is probably true, though I also worry a bit whether there are archs where it does something inefficient or broken. Ideally the compiler would be able to recognize portable (within IEEE) patterns for floating point representation examination and optimize them if there's a more efficient way to be able to do it for a particular machine. Rich