[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260819124819.GE23438@brightrain.aerifal.cx>
Date: Wed, 19 Aug 2026 08:48:19 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com, Sergey Davidoff <shnatsel@...il.com>
Subject: Re: [PATCH v3] math: fmaf fixes
On Tue, Aug 18, 2026 at 09:10:35PM +0200, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@...t70.net> [2026-08-17 02:22:33 +0200]:
> > the new code uses that for all real |x| in [0x1p-999,0x1p999]
> >
> > y = (float)x
> >
> > is the same as
> >
> > r = (double)x
> > t = x - r
> > if (t!=0 && (r.bits&0xfffffff)==0)
> > r.bits += (r<0)==(t<0) ? 1 : -1
> > y = (float)r
> >
> > in all rounding modes, with the same fenv effects. note: using
> > r.bits&1 this can be interpreted as a round to odd adjustment,
> ...
> > + if ((u.i & 0xfffffff) == 0 && e < 0x3ff+128) {
> > + /* correct except for inf, nan and some (r&1)==1 cases.
> > + * r+t == x*y+z exactly in nearest rounding mode and in
> > + * other modes the t!=0 and t<0 checks are not affected.
> > + * if t==0 then inexact is not signaled. */
> > + int s = u.i >> 63;
> > + double t = s == (xy < z) ? xy - u.r + z : z - u.r + xy;
> > + if (t)
> > + /* adjust r toward r+t */
> > + u.i += s == (t < 0) ? 1 : -1;
> > + }
>
> round to odd (with sr,st in 0,1):
>
> if (u%2 == 0)
> u += sr == st ? 1 : -1;
>
> can be written as
>
> u -= sr ^ st;
> u |= 1;
>
> compilers don't seem to do this transformation, but then
> u&0xfffffff can be removed without making the adjust more
> expensive. this saves some bytes and may only regress
> subnormal range cases a bit. maybe a better tradeoff.
Do you want to pursue this or just go with the patch as-is?
Rich
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.
