On Fri, 2023-11-24 at 16:36 +0800, chenglulu wrote:
>
> 在 2023/11/24 下午4:26, Xi Ruoyao 写道:
> > On Fri, 2023-11-24 at 16:01 +0800, chenglulu wrote:
> > > I only saw lrint llrint in n2310 with this description:
> > >
> > > F7.12.9.5
> > >
> > > "The lrint and llrint functions round their argument to the nearest
> > > integer value, rounding
> > > according to the current rounding direction. If the rounded value is
> > > outside the range of the return
> > > type, the numeric result is unspecified and a domain error or range
> > > error may occur."
> > >
> > > I don't know if I'm right?
> > There's an explanation in the linux man-page for lrint:
> >
> > SUSv2 and POSIX.1‐2001 contain text about overflow (which might set
> > er‐
> > rno to ERANGE, or raise an FE_OVERFLOW exception). In practice,
> > the
> > result cannot overflow on any current machine, so this
> > error‐handling
> > stuff is just nonsense. (More precisely, overflow can happen only
> > when
> > the maximum value of the exponent is smaller than the number of
> > man‐
> > tissa bits. For the IEEE‐754 standard 32‐bit and 64‐bit
> > floating‐point
> > numbers the maximum value of the exponent is 127 (respectively,
> > 1023),
> > and the number of mantissa bits including the implicit bit is 24
> > (re‐
> > spectively, 53).)
> >
> This is the description of rint rintf rintl in the linux man-page.:-(
Phew, I misread the message.
Yes, for lrint we assume it may set errno. For example:
long x[4];
double y[4];
void test()
{
for (int i = 0; i < 4; i++)
x[i] = __builtin_lrint(y[i]);
}
We produce a loop calling lrint with -O2 -mlasx:
.L2:
fldx.d $f0,$r26,$r23
bl %plt(lrint)
stx.d $r4,$r25,$r23
addi.d $r23,$r23,8
bne $r23,$r24,.L2
because using xvftint.l.d may miss an errno from the libc. Only with -
O2 -mlasx -fno-math-errno xvftint.l.d is emitted.
But for
long x[4];
double y[4];
void test()
{
for (int i = 0; i < 4; i++)
x[i] = (long) __builtin_rint(y[i]);
}
we know rint does not set errno, and converting a double to long does
not set errno, so using xvftint.l.d is correct.
On the contrary, we cannot optimize it to the first example because it
may cause an errno to be mistakenly set when the libc sets errno for
lrint. That's why the generic code only transforms (int)rintf -> irintf
or (long)rint -> lrint when -ffast-math.
But this limitation does not apply for the xvftint.l.d instruction (as
xvftint.l.d is just an instruction and it does not know errno at all).
--
Xi Ruoyao <xry...@xry111.site>
School of Aerospace Science and Technology, Xidian University
