[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DBCC9A601F614AA6AC6B7F6E4922C667@H270>
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.
