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 57B4D385829B for ; Fri, 24 Nov 2023 02:39:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 57B4D385829B 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 57B4D385829B 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=1700793548; cv=none; b=GomcqPXLtSSxBspMvEBYiDB1kuncIkmsTxOSts9uhXO+ZKpn717XqA+KYStqmRqm6zHDVpsG0f+u2kPGV3MMmpjK+W/kGiOZw1JFs0HIL8rCW9yFKoqSghHJDPs0D0137Owt9/J5CvPDOHo+r5V9EeRCd20caOqzmsinAC0ZA8I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700793548; c=relaxed/simple; bh=QANDntkpZNWybc9Vt/NBc12rNd1lS0BvBElcpGJ2/Rc=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=pRubQlUmaE8xHmWo95aM7UxcuYRv/DUUUSiWDQ1S8P/ySaKDM+Nmygf+Pq2ht3MVXFzLuFy0PlA4DxtrBU7vfiaCVWcpdbDrdVplWgD29M4P56EWlodaT8Sp9+exDNX8iFtI3yyPiQzbYkPslA02C3L4+7z/lqPRzOhXfykLaYc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1700793543; bh=QANDntkpZNWybc9Vt/NBc12rNd1lS0BvBElcpGJ2/Rc=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=f/zPfPO9oxdODlhpxSHnKfoxaeDc2pF9qSxFvBzGsIujSuoXfXUf//cCpW2THRMm4 JHyvcv/0VX/S6jImiBcKAfMsKX+yHGU9WBewMY2OGloQ0+/bhRswrjDhggasyicFas ky1TVAnTYy3QL3UVP4DnghVYSXJdbYKzQvKi3j9I= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (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 0307F66B39; Thu, 23 Nov 2023 21:39:01 -0500 (EST) Message-ID: Subject: Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578] From: Xi Ruoyao To: Joseph Myers , chenglulu Cc: gcc-patches@gcc.gnu.org, Uros Bizjak , i@xen0n.name, xuchenghua@loongson.cn Date: Fri, 24 Nov 2023 10:39:00 +0800 In-Reply-To: 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> 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.1 MIME-Version: 1.0 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,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 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=20 > errors, at least if you ignore the option for signaling NaNs arguments to= =20 > be domain errors - which is in TS 18661-1, but not what glibc does, and= =20 > not in C23). >=20 > The lrint / llrint functions should logically set errno for a domain erro= r=20 > in the cases where they raise "invalid".=C2=A0 That they don't in glibc i= s=20 > glibc bug 6798.=C2=A0 And __builtin_irint functions can fall back to call= ing=20 > lrint functions if not expanded inline.=C2=A0 So the potential for errno= =20 > 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 don't see an obvious need for -funsafe-math-optimizations here - but at= =20 > least -fno-trapping-math should be needed in some cases.=C2=A0 That's bec= ause=20 > rint raises "inexact" for noninteger argument - but lrint doesn't raise= =20 > "inexact" when raising "invalid".=C2=A0 So if, for example, long is 32-bi= t and=20 > the floating type in use is double, calling rint for a noninteger argumen= t=20 > too large for long, and then converting to a 32-bit signed integer type= =20 > (long or int), raises both "inexact" and "invalid" - but a direct call to= =20 > 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? --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University