From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 51E2B3858C60 for ; Fri, 24 Nov 2023 09:46:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 51E2B3858C60 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 51E2B3858C60 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=114.242.206.163 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700819205; cv=none; b=Ki5oahRlemgirGoj5MTGPnl+qewFYm76Xj/bN/DDIgAigOIEpfZkiP42XG+PgZi9wbm7DIOTobqVPP4jx632iguKdLa3UkPreSgg5TvTN0w92/tE2yt6Xt/ROS/F6W24LHuugaTQCBM8OoSppr0WZ0UgdxPceDRTAMB5N8CVPKc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700819205; c=relaxed/simple; bh=lLF9awnBVOIRWSDIk9TzqVz1yu1sI8sLKASPzHjAKeM=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=q8gEPG/Am+8lhZth5sK+NBDN5GCIsNFK0i7rc8Xmcc7EHp7B1rSRsUJuMXY9v8cGOFmBfSIKEeAA9Jjn1Tn6Phjevqe2h8JSOMe8nR9LE3zA73njcUQfJCMj9lei9+1gnZyarU0JO9pwwZ7XckDKmQwcuoCyvVfVUg0qZa6s2wE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from loongson.cn (unknown [10.20.4.107]) by gateway (Coremail) with SMTP id _____8BxJvH_cGBl5Ik8AA--.54757S3; Fri, 24 Nov 2023 17:46:40 +0800 (CST) Received: from [10.20.4.107] (unknown [10.20.4.107]) by localhost.localdomain (Coremail) with SMTP id AQAAf8DxjNz+cGBlV4VLAA--.35651S3; Fri, 24 Nov 2023 17:46:39 +0800 (CST) Subject: Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578] To: Xi Ruoyao , Joseph Myers Cc: gcc-patches@gcc.gnu.org, Uros Bizjak , i@xen0n.name, xuchenghua@loongson.cn References: <20231120004728.205167-1-xry111@xry111.site> <20231120004728.205167-2-xry111@xry111.site> <2d1c9d59544d15ef7fba07d758431da840cc0bfe.camel@xry111.site> <9ce7e0b2-eeeb-a8c5-2cc7-e9b65b1b2a6b@loongson.cn> <0fc6f3d2536b6d2d8a1e86a5e17354f89ba7040a.camel@xry111.site> <29426aaa-8bd6-c63c-2c9a-0ba7d007582a@loongson.cn> <1ab40b49c384517ca38f528fda96e688eae210db.camel@xry111.site> From: chenglulu Message-ID: <97012389-18f1-97ee-24b3-778c5728aa54@loongson.cn> Date: Fri, 24 Nov 2023 17:46:38 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <1ab40b49c384517ca38f528fda96e688eae210db.camel@xry111.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8DxjNz+cGBlV4VLAA--.35651S3 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBj93XoWxZryxurW3ZFWUWrWUWF48GrX_yoW5ZF45pa 97AFWqkFZ5CF18Zr4jyw48JFy5tF17Ja15Xr1kGFyUAws0vr92gFWavw1qgFyUGr40qw1a vw4jqry3uF18ZagCm3ZEXasCq-sJn29KB7ZKAUJUUUU7529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUB2b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2kKe7AKxVWUXVWUAwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07 AIYIkI8VC2zVCFFI0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWU AVWUtwAv7VC2z280aVAFwI0_Gr0_Cr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI4 8JMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_ Jr0_Gr1l4IxYO2xFxVAFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8Gjc xK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0 cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8V AvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E 14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxU2uc_DUUUU X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 在 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.