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 17943 invoked from network); 10 Aug 2021 23:10:32 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Aug 2021 23:10:32 -0000 Received: (qmail 6131 invoked by uid 550); 10 Aug 2021 23:10:30 -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 6113 invoked from network); 10 Aug 2021 23:10:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexgo.de; s=vfde-smtpout-mb-15sep; t=1628636956; bh=kSqdfdEsPzekl5V7CToxdJCIrJg5p+fm5ljDRjvVilY=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=UXn+tUGXhcxz4i/ueX7RWkbSEO3wZsR1tcayRJWxPIP9cmo24E8mLIg8GZmB/5n/f EvUI1ORfQx2794/W0rd6TRiX75WTxKZqwjK6pQANkBYYbMX2Q8MsSEFlerC06z2ibd o5k9ErMaIuZ344qjzE9MyVXOz1ti2MHIKp1a7Xq0= Message-ID: <5C60D05C95724A36B3DB9942D06CFE5F@H270> From: "Stefan Kanthak" To: "Szabolcs Nagy" Cc: References: <0C6AAAD55DA44C6189B2FF4F5FB2C3E7@H270> <20210810213455.GB37904@port70.net> In-Reply-To: <20210810213455.GB37904@port70.net> Date: Wed, 11 Aug 2021 00:53:37 +0200 Organization: Me, myself & IT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-purgate-size: 3122 X-purgate-ID: 155817::1628636956-00000B26-5A1934C9/0/0 Subject: Re: [musl] [PATCH] Properly simplified nextafter() Szabolcs Nagy wrote: >* Stefan Kanthak [2021-08-10 08:23:46 +0200]: >> >> has quite some superfluous statements: >> >> 1. there's absolutely no need for 2 uint64_t holding |x| and |y|; >> 2. IEEE-754 specifies -0.0 == +0.0, so (x == y) is equivalent to >> (ax == 0) && (ay == 0): the latter 2 tests can be removed; > > you replaced 4 int cmps with 4 float cmps (among other things). and hinted that the result of the second pair of comparisions is already known from the first pair. > it's target dependent if float compares are fast or not. It's also target dependent whether the floating-point registers can be accessed by integer instructions, or need to be copied: some win, some loose! Just let the compiler/optimizer do its job! > (the i386 machine where i originally tested this preferred int > cmp and float cmp was very slow in the subnormal range and > iirc it also raises the non-standard input denormal exception, > which is fine i guess. This exception resp. the (sticky) flag is explicitly raised/set in the part following the patch. > of course soft float abis much prefer int cmp so your code is > likely much slower and bigger there). 0. Doesn't musl provide target specific routines for targets with soft FP? 1. If not: the compiler knows the target ABI and SHOULD generate the proper integer comparisions there. > but i'm not against the change, it is likely better on modern > machines. did you try to benchmark it? or check the code size? I STILL don't run a system supported by musl. The code is of course smaller ... but not as small and fast as a proper i386 or AMD64 assembly implementation ... which I can post upon request. regards Stefan >> 3. there's absolutely no need to compare the signs of x and y >> with the sign of the direction: its sufficient to test that >> direction and sign of x match; >> 4. a proper compiler/optimizer should be able to reuse the results >> of the comparision (x == y) for (x < y) or (x > y) and >> (x == 0.0) for (x < 0.0) or (x > 0.0). >> >> JFTR: if ((x < 0.0) == (x < y)) is equivalent to >> if ((x > 0.0) == (x > y)) >> >> --- -/src/math/nextafter.c >> +++ +/src/math/nextafter.c >> @@ -3,20 +3,15 @@ >> double nextafter(double x, double y) >> { >> union {double f; uint64_t i;} ux={x}, uy={y}; >> - uint64_t ax, ay; >> int e; >> >> if (isnan(x) || isnan(y)) >> return x + y; >> - if (ux.i == uy.i) >> + if (x == y) >> return y; >> - ax = ux.i & -1ULL/2; >> - ay = uy.i & -1ULL/2; >> - if (ax == 0) { >> - if (ay == 0) >> - return y; >> + if (x == 0.0) >> ux.i = (uy.i & 1ULL<<63) | 1; >> - } else if (ax > ay || ((ux.i ^ uy.i) & 1ULL<<63)) >> + else if ((x < 0.0) == (x < y)) >> ux.i--; >> else >> ux.i++;