From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 894A73861819 for ; Fri, 24 Nov 2023 08:01:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 894A73861819 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=loongson.cn ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 894A73861819 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700812903; cv=none; b=fEd9RbICuLrFzM3AF4sed84oaEKz59tEZeirjMa6v02RqIGchHeUS95qFvGhq9MFDHz4LBDmbiapZfhwKwFr02VYAdvbEnqUgZaackwPwfgAR3zbsqcOLfGKxHF4y5DK0AIbWZtKvPRKbqY90t0TSk55EKm6HJ3EZXEBjJcCKnI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700812903; c=relaxed/simple; bh=kQOlRhJc9tDqEcT/mFysn+YYt2+4u1N6z3c0l9x8mSQ=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=lRvPDv4sffBDzsykTu+slIlxqB6awuQlv3RI6KALqb+G5gjeBA7AikU9fQikgE24KHPRDx1ZKxVzY3aKqxXDQQE8GEX13jKhPvxekfPE3XYYT/e3W7kIJpCsw/Uxr+gbSD2E0T2+mzdRZVdHDWZH7tQiiumL7QP8MJvzZKVUPFg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mail.loongson.cn ([114.242.206.163]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r6R85-0007VB-Ia for gcc-patches@gcc.gnu.org; Fri, 24 Nov 2023 03:01:41 -0500 Received: from loongson.cn (unknown [10.20.4.107]) by gateway (Coremail) with SMTP id _____8AxEvBUWGBl8oQ8AA--.54010S3; Fri, 24 Nov 2023 16:01:25 +0800 (CST) Received: from [10.20.4.107] (unknown [10.20.4.107]) by localhost.localdomain (Coremail) with SMTP id AQAAf8AxXNxTWGBlcnZLAA--.35583S3; Fri, 24 Nov 2023 16:01:24 +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> From: chenglulu Message-ID: Date: Fri, 24 Nov 2023 16:01:23 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8AxXNxTWGBlcnZLAA--.35583S3 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBj93XoWxJF45Aw4DCF45JrW7XFW7WrX_yoW5Jw1Upa 15KF15C3yqyr4xCrsrAayrX3WSqFZ7J3y5Grs3X342yrs8Xa4ktFWayr1akas8Wr1rJ3W0 vay29wn3u3WYyagCm3ZEXasCq-sJn29KB7ZKAUJUUUUr529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUU90b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2kKe7AKxVWUXVWUAwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07 AIYIkI8VC2zVCFFI0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWU XVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI4 8JMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_ Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1V AY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAI cVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42 IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVj vjDU0xZFpf9x07jjwZcUUUUU= Received-SPF: pass client-ip=114.242.206.163; envelope-from=chenglulu@loongson.cn; helo=mail.loongson.cn X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9,NICE_REPLY_A=-1.672,SPF_HELO_NONE=0.001,SPF_PASS=-0.001,T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_FAIL,SPF_HELO_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 上午10:39, Xi Ruoyao 写道: > On Thu, 2023-11-23 at 18:03 +0000, Joseph Myers wrote: >> The rint functions indeed don't set errno (don't have domain or range >> errors, at least if you ignore the option for signaling NaNs arguments to >> be domain errors - which is in TS 18661-1, but not what glibc does, and >> not in C23). >> >> The lrint / llrint functions should logically set errno for a domain error >> in the cases where they raise "invalid".  That they don't in glibc is >> glibc bug 6798.  And __builtin_irint functions can fall back to calling >> lrint functions if not expanded inline.  So the potential for errno >> setting explains why -fno-math-errno is required. > I agree. But this is not preventing optimizing vectorized "(int) > rintf(x[i])" into a vftint.w.s instruction which does not set errno. I'm sorry. Please forgive my stupidity. I don't see a description in TS 18661-1 that explicitly says rint does not set errno. 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? > >> I don't see an obvious need for -funsafe-math-optimizations here - but at >> least -fno-trapping-math should be needed in some cases.  That's because >> rint raises "inexact" for noninteger argument - but lrint doesn't raise >> "inexact" when raising "invalid".  So if, for example, long is 32-bit and >> the floating type in use is double, calling rint for a noninteger argument >> too large for long, and then converting to a 32-bit signed integer type >> (long or int), raises both "inexact" and "invalid" - but a direct call to >> lrint raises such "invalid". > Interesting... But for (i32)rintf(x) it's impossible to have a non- > integer value out of [-2147483648, 2147483648) except NaN and +-Inf, > likewise for (i64)rint(x). So using vftint.w.s and vftint.l.d > instructions should still be fine. We also have a vftint.w.d > instruction but it's only used as an intrinsic as at now, and my patch > does not attempt to use it. > > Lulu: so my conclusion is an (i32)rintf -> irintf transformation is > indeed "unsafe" generally, but a machine-specific transformation to > vftint.w.s is fine and we should use the define_insn to do it. Do you > agree? >