在 2023/11/24 下午4:42, Xi Ruoyao 写道:
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).
Yeah, I know what you mean. That is, our handling of errno and exception
flag bits
before and after optimization is unchanged, then the optimization is no
problem.
So I agree with your optimization.
It's just that I'm confused that the description of rint in n2310,
including Joseph's email,
all say that rint will not set errno, but linux-man says "which might
set errno to ERANGE" .
The two aspects about rint lrint's handling of errno are opposite.
