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 5A71B3858D28 for ; Thu, 23 Nov 2023 10:12:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A71B3858D28 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 5A71B3858D28 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=1700734372; cv=none; b=k0uEHih2IWULL3tevyJ23T0JqaF1AYBfHjQMXYEBI3oq8xzx/N8eAWdvsB8qwFUNkX4xBefzLKXJ/09RDJ64SLTwYZp1viSN0ZZe9VQx5NQPxYPBryAf9Wy/lS6bGbSiT4Y7VX0FHrdCi1d19I2RT6qFHiNUij6VXPUKeDukp4Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700734372; c=relaxed/simple; bh=xksTPVT4S1xtokE/jlpwfNzRyLZb5KKF0jkqu1mZKyQ=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=SP+Pty+eAEeMLyisCGK9UJ4036Dyu3fs/BgFZOcNA+RUJttBYxHNPkeJ38CAQgcBSlG0gQEpCDbk/YGmvfdBLKu7cNOvhjnPjBubr1I5pImqMGQTpGM/8zGHsBU70XerlrepTGsoswsk1oFUIXgqveWyXSufdyXEIWH0wKEhP60= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1700734365; bh=xksTPVT4S1xtokE/jlpwfNzRyLZb5KKF0jkqu1mZKyQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Ko/OFj0hyTDbJuRqHwh9SsDpHSe9OLU2SHJZdQMMXQVC2BJkC1BJGqFvoF2h9ul9q S6sbJISgS1x26OUdPz4N8JsJTNDDzG64S9vTM7gWqMQtz71o8w4gGnyTRGC0oaC7jm FcGcKh8sD2YRcybngkG7VPacl5yMnADlNdik75lw= Received: from [192.168.124.20] (unknown [113.200.174.103]) (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 2A0BB66B39; Thu, 23 Nov 2023 05:12:42 -0500 (EST) Message-ID: <0fc6f3d2536b6d2d8a1e86a5e17354f89ba7040a.camel@xry111.site> Subject: Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578] From: Xi Ruoyao To: chenglulu , gcc-patches@gcc.gnu.org, Uros Bizjak , Joseph Myers Cc: i@xen0n.name, xuchenghua@loongson.cn Date: Thu, 23 Nov 2023 18:12:37 +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> 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.5 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 17:12 +0800, chenglulu wrote: >=20 > =E5=9C=A8 2023/11/23 =E4=B8=8B=E5=8D=885:02, Xi Ruoyao =E5=86=99=E9=81=93= : > > On Thu, 2023-11-23 at 16:13 +0800, chenglulu wrote: > > > The fix_truncv4sfv4si2 template is indeed called when debugging with > > > gdb. > > >=20 > > > So I think we can use define_expand here. > > The problem is cases where we want to combine an rint call with float- > > to-int conversion: > >=20 > > float x[4]; > > int y[4]; > >=20 > > void test() > > { > > for (int i =3D 0; i < 4; i++) > > y[i] =3D __builtin_rintf(x[i]); > > } > >=20 > > With define_expand we get "vfrint + vftintrz", but with define_insn we > > get a single "vftint". > >=20 > > Arguably the generic code should try to handle this (PR86609), but it's > > "not sure if that's a good idea in general" (comment 1 in the PR) so we > > can do this in a target-specific way. > >=20 > I tried to use Ofast to compile, and found that a vftint was generated,= =20 > and at.006t.gimple appeared. >=20 > If O2 was compiled, __builtin_rintf would be generated, but Ofast would= =20 > generate __builtin_irintf Indeed... It seems the FE will only generate __builtin_irintf when - fno-math-errno -funsafe-math-optimizations. But I cannot see why this is necessary (at least for us): the rintf function does not set errno at all, and to me using vftint.w.s here is safe: if the rounded result can be represented as a 32-bit int, obviously there is no issue; otherwise, per C23 section F.4 we should raise FE_INVALID and produce unspecified result. It seems our ftint.w.s instruction has the required semantics. +Uros and Joseph for some comment about the expected behavior of (int)rintf(x). --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University