From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13893 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: FE Exception triggered by comparison Date: Wed, 27 Feb 2019 20:36:13 +0100 Message-ID: <20190227193613.GG21289@port70.net> References: <20190225155109.GB28106@voyager> <20190227164225.GV23599@brightrain.aerifal.cx> <20190227172641.GW23599@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="29922"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13909-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 27 20:36:28 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 1gz50F-0007iK-Pr for gllmg-musl@m.gmane.org; Wed, 27 Feb 2019 20:36:27 +0100 Original-Received: (qmail 14119 invoked by uid 550); 27 Feb 2019 19:36:25 -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 14101 invoked from network); 27 Feb 2019 19:36:25 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20190227172641.GW23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13893 Archived-At: * Rich Felker [2019-02-27 12:26:41 -0500]: > 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. e.g. isnan is broken with -fsignaling-nan since it should not signal but the ucomisd gcc generates does as discussed. (although it's unlikely to matter much: we dont support snan in all apis) but gcc used to generate horrible code for fpclassify things, nowadays it should be mostly fixed, i don't remember if there were actual correctness bugs or just inefficient code. > > 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