Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]

[chenglulu <chenglulu@loongson.cn>]

在 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.