Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Aug 2021 20:30:00 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: "Rich Felker" <dalias@...c.org>
Cc: "Szabolcs Nagy" <nsz@...t70.net>,
	<musl@...ts.openwall.com>
Subject: Re: [PATCH #2] Properly simplified nextafter()

Rich Felker <dalias@...c.org> wrote:

> On Fri, Aug 13, 2021 at 02:04:51PM +0200, Stefan Kanthak wrote:
>> Szabolcs Nagy <nsz@...t70.net> wrote on 2021-08-10 at 23:34:
>> 
>> >* Stefan Kanthak <stefan.kanthak@...go.de> [2021-08-10 08:23:46 +0200]:
>> >> <https://git.musl-libc.org/cgit/musl/plain/src/math/nextafter.c>
>> >> 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).
>> > 
>> > it's target dependent if float compares are fast or not.
>> 
>> It's also target dependent whether the FP additions and multiplies
>> used to raise overflow/underflow are SLOOOWWW: how can you justify
>> them, especially for targets using soft-float?
> 
> On a target with fenv, raising the exception flags is mandatory and
> something must be done to make that happen. Performing the arithmetic
> is far faster than prodding at the status flag registers explicitly.

I did NOT propose the latter; I just questioned whether/why you use
two multiplications to detect underflow.

JFTR: FORCE_EVAL(dummy+0.0); raises both overflow and underflow,
      without multiplication.

> On a target without fenv (all the existing soft float targets), it
> should be valid for the compiler just not to emit them, since they
> have no side effects. I think we could make FORCE_EVAL expand to
> nothing on such targets (if the FE_* macros are not defined). This is
> probably worth doing.

Correct, that's the right thing to do there.

[ buggy compiler ]

> It may be possible to reduce the number of such ops too; not sure. But
> there's no way to eliminate them.

It's definitely possible to do a strength reduction and get rid of the
multiplications.

Stefan

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.