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.3 required=5.0 tests=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 25193 invoked from network); 14 Aug 2021 22:45:27 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 14 Aug 2021 22:45:27 -0000
Received: (qmail 32270 invoked by uid 550); 14 Aug 2021 22:45:24 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 32252 invoked from network); 14 Aug 2021 22:45:24 -0000
Date: Sun, 15 Aug 2021 00:45:12 +0200
From: Szabolcs Nagy <nsz@port70.net>
To: Damian McGuckin <damianm@esi.com.au>
Cc: musl@lists.openwall.com
Message-ID: <20210814224512.GG37904@port70.net>
Mail-Followup-To: Damian McGuckin <damianm@esi.com.au>,
	musl@lists.openwall.com
References: <0C6AAAD55DA44C6189B2FF4F5FB2C3E7@H270>
 <20210810213455.GB37904@port70.net>
 <E2423D1F1F3848848AEA933048174858@H270>
 <20210813155917.GE13220@brightrain.aerifal.cx>
 <DBCC9A601F614AA6AC6B7F6E4922C667@H270>
 <alpine.LRH.2.02.2108141354270.8681@key0.esi.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.02.2108141354270.8681@key0.esi.com.au>
Subject: Re: [musl] [PATCH #2] Properly simplified nextafter()

* Damian McGuckin <damianm@esi.com.au> [2021-08-14 14:07:34 +1000]:
> On Fri, 13 Aug 2021, Stefan Kanthak wrote:
> > > It may be possible to reduce the number of such ops too; not sure. But
> > > there's no way to eliminate them.
> 
> Replacing the second FORCE'd expression with
> 
> 	FORCE((ux.f + x) * (0x1.0p-52 * 0.25));
> 
> eliminates one floating point OP, assuming the optimiser does the right
> thing to
> 
> 	epsilon / 4
> 
> in the expression. Some preliminary testing seems to suggest that the same
> exceptions get raised.
> 
> > It's definitely possible to do a strength reduction and get rid of the
> > multiplications.
> 
> But then how is the exception still raised, or are we talking soft FP?

that does not work, i think.

but the subnormal result case is not worth optimizing.
(or rather, i prefer to optimize cold code paths for size)