From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 7D37C3858006 for ; Wed, 31 Jan 2024 09:08:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7D37C3858006 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7D37C3858006 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706692131; cv=none; b=l6Dkf+4KZ1sfBm6SiFAhOKgSLdgti75+PJJbc7PQMzJ5vU/H+ww9UcsxG/Ka8VQmHK2w6bL5J+P88nyOZGK1ia+idNuRek0AxCZ4IxSH8ekHuq45Mr4hDiindgQ1LktCF/aXZ0ct0SLSS+1bEIYJatDR48y3oeSVLOJcKansRSc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706692131; c=relaxed/simple; bh=3U8YRzHachvb1wmipbDCL82dQE0gT6UND/Om4x53v0A=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=TgARnLA8sW5PiqUs5y5aLGVf4IypeGUfWT9h70gb/DgySvxPw9yIdUyghnvS+T7HDdPSU2xE7+/NhAUl9eF86KwXa6wNxMNjVDGiJ4eFIcevvZuYQj0M1Y5ewWyAvnRL4OWjqHNApIXFYLJBMaxn0wIceHGjAfNvogC8LMM194I= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1706692127; bh=3U8YRzHachvb1wmipbDCL82dQE0gT6UND/Om4x53v0A=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=jNknzCnlutq5C3SDSRa/Hc8jHuekgLcV0RhNBe6E1N1eEbYEDzO5Yf0jxS0TSwyjE /qYP4BJHJvmJZGRobzk6g8++ey6jw5Uy7JMmHMvN/HRcp0GcvlcExpTVOZRUmUAtf2 FGrD2gl/A0vgwMGmcFo8eZaFTY4xgaGdHKhBdd2Q= Received: from [IPv6:240e:358:114f:d600:dc73:854d:832e:2] (unknown [IPv6:240e:358:114f:d600:dc73:854d:832e:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 04D4A66B59; Wed, 31 Jan 2024 04:08:45 -0500 (EST) Message-ID: <7d6ec9e35a9bbf55df7ba2ae0b228a30ed6349b7.camel@xry111.site> Subject: Re: [PATCH 2/2] MIPS: Hard-float rounding instructions support From: Xi Ruoyao To: Junxian Zhu Cc: libc-alpha@sourceware.org Date: Wed, 31 Jan 2024 17:08:36 +0800 In-Reply-To: <5f0f4c83-f6d8-4af3-8cce-e12cd5314da1@oss.cipunited.com> References: <20231225103548.1615-2-zhujunxian@oss.cipunited.com> <20231225103548.1615-4-zhujunxian@oss.cipunited.com> <5f0f4c83-f6d8-4af3-8cce-e12cd5314da1@oss.cipunited.com> Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual; keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.3 MIME-Version: 1.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 2024-01-31 at 11:28 +0800, Junxian Zhu wrote: > =E5=9C=A8 2023/12/26 16:29, Xi Ruoyao =E5=86=99=E9=81=93: > > On Tue, 2023-12-26 at 10:37 +0800, Junxian Zhu wrote: > > > =E5=9C=A8 2023/12/25 18:51, Xi Ruoyao =E5=86=99=E9=81=93: > > > > On Mon, 2023-12-25 at 18:35 +0800, Junxian Zhu wrote: > > > >=20 > > > > /* snip */ > > > >=20 > > > > > +/* > > > > > + * ceil(x) > > > > > + * Return x rounded toward -inf to integral value > > > > > + * Method: > > > > > + * Bit twiddling. > > > > > + */ > > > > > + > > > > > +#if ((__mips_fpr =3D=3D 64) && (__mips_hard_float =3D=3D 1) && > > > > > ((__mips =3D=3D 32 && __mips_isa_rev > 1) || __mips =3D=3D 64)) > > > > > +#include > > > > > +#include > > > > > +#include > > > > > + > > > > > +ENTRY(__ceil) > > > > > + .set push > > > > > + .set noreorder > > > > > + .set noat > > > > > +# $f0=3Dret, $f12=3Ddouble, a0=3Dint64/int32_h, a1=3Dint32_l, > > > > > a2=3Dsign, a3=3Dexp > > > > > +#if __mips =3D=3D 64 > > > > > + dmfc1=C2=A0=C2=A0 a0, $f12 # assign int64 > > > > > +#else > > > > > + mfhc1=C2=A0=C2=A0 a0, $f12 # assign int64 > > > > > +#endif > > > > > + cfc1=C2=A0=C2=A0=C2=A0 t0, $f26 > > > > > + ceil.l.d=C2=A0=C2=A0=C2=A0 $f0, $f12 > > > > No, C23 does not allow this function to raise an INEXACT > > > > exception, but > > > > ceil.l.d will do so. > > > >=20 > > > > Such optimizations should be performed in GCC which can be > > > > controlled by > > > > the programmer with -std=3Dc23 and/or -f[no-]fp-int-builtin- > > > > inexact, not > > > > in Glibc where we cannot know if the programmer wants to deviate > > > > from > > > > C23. > > > The cfc1 instruction will backup float point exception status > > > before > > > running ceil.l.d, and the following ctc1 will restore float point > > > exception status to avoid INEXACT exception raised by ceil.l.d. > > > It's the > > > same way like what have been done in s_ceil.S for i386. > > Still incorrect because when the Enable field of FCSR contains > > INEXACT a > > SIGFPE will be immediately delivered and there is no way to > > recover.=C2=A0 A > > demonstration: > >=20 > > #define _GNU_SOURCE > > #include > > #include > >=20 > > int main() > > { > > =C2=A0=C2=A0 printf("%d\n", feenableexcept(FE_INEXACT)); > >=20 > > =C2=A0=C2=A0 double data =3D 114.514; > > =C2=A0=C2=A0 long control; > > =C2=A0=C2=A0 asm("cfc1\t%1,$f26\n\t" > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "ceil.l.d\t%0,%0\n\t" > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "cvt.d.l\t%0,%0\n\t" > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "ctc1\t%1,$f26": "+f"(data), "=3Dr= "(control)); > > =C2=A0=C2=A0 printf("%.15f\n", data); > > =C2=A0=C2=A0 return 0; > > } > >=20 > > On i386 the fnstenv instruction also masks out all the FP exceptions > > so > > this is not a problem.=C2=A0 See commit 26b0bf96000a. >=20 > I made some similar code to test and found that sqrt.fmt on MIPS will=20 > raise INEXACT exception too. >=20 > So should we mask all the FP exceptions while compiling MIPS=20 > SQRT{F}_BUILTIN in GCC ? (for C23) Why? volatile double x =3D 2; sqrt(x);=20 should definitely raise an INEXACT exception. Unless explicitly stated otherwise, all operations producing a result different than the "infinite precision operation" should do it. For the conversion operations they are just "explicitly stated otherwise." But if sqrt.fmt is raising it for volatile double x =3D 4; sqrt(x);=20 it's obviously wrong, and I'd say such an exception is nonsense even regardless of the standard so we should just not use this instruction. Something not so obvious is: the standard explicitly says volatile double x =3D __builtin_inf(); sqrt(x);=20 should **not** raise an INEXACT exception. So if you are raising INEXACT for this you should only use sqrt.fmt when you can prove the operand is finite (for example when -ffinite-math-only, or using some information from the VRP pass). --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University