From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 14A933858D35 for ; Thu, 23 Nov 2023 18:03:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 14A933858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 14A933858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=68.232.129.153 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700762621; cv=none; b=kphthGiGy6A9R2OWRPYIaa1Twpr6WmsDcuHgFj4NGW/izO+BZad4ZBr+OxBkjcbXhS7GrjQ5uVE1VoE8uI9+6HMPxYbzYfAvasovYfr5BauADU/Sup6Zy6xEQvHaGFsD4bUeRmR6XjndcApvrPbQrumYeVUgZY3ipHiy6j8QoKg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700762621; c=relaxed/simple; bh=y7cPBQZj7mjl/tK7v2g1I51S9RL83pJU73/vq4OEqsI=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=Vf/TJFn78VReIH3/bzo69SeqOerStQWDVM28JFlvBQc3AKJB8VAW8pCb7dLY2cNJosIU7gylGO5rW46wwX70eHzl2r9o/rQ/eGsZO7zLIrokZ97RYb5CvR+bza6rqglQwFTNXOdE1zU03qhBLSJNgbrJ0VVRN8XoFw/TC4KclLo= ARC-Authentication-Results: i=1; server2.sourceware.org X-CSE-ConnectionGUID: k65GkhFWSB+EdsiAa2Gq4g== X-CSE-MsgGUID: +4zVWtmoRLSUez/cGAJyMQ== X-IronPort-AV: E=Sophos;i="6.04,222,1695715200"; d="scan'208";a="26623782" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 23 Nov 2023 10:03:38 -0800 IronPort-SDR: Z4PIS8vNptKU9/0r0/p3kuviSb6z1Uia1X6pKmwnp62ora+lkyzGXiuu9HFP6Z3p7GiFFacIFC +OuHX19H+PCZAHLd+7KnAOHSY92Aksgez2QLlwWdTn35qOgKYnWZn76e8V+7oxb2ivHtOc5ysR 7AdMbc7YQ+9VPccjrhnAuvfXIliRTgq7ED8AKGb3d/SNEZdY3dCYXaZfPXjVM1XDTjmJVRLxRR iYI9KKl+eg3/HXhstewFRwKA084utl4tfwx3YMYj5z57BNd9zihdaVjODmiXJblyBOuDl781C/ xPI= Date: Thu, 23 Nov 2023 18:03:34 +0000 From: Joseph Myers To: Xi Ruoyao CC: chenglulu , , Uros Bizjak , , Subject: Re: [PATCH v3 1/5] LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578] In-Reply-To: <0fc6f3d2536b6d2d8a1e86a5e17354f89ba7040a.camel@xry111.site> Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-13.mgc.mentorg.com (139.181.222.13) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3103.1 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,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, 23 Nov 2023, Xi Ruoyao wrote: > 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. 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 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". There are plausible arguments for both -fno-math-errno and -fno-trapping-math as defaults, or at least a subset of -fno-trapping-math (such as allowing code transformations that don't raise new exceptions but might lose some exceptions). The comment in convert.cc about why -funsafe-math-optimizations is required says: /* Convert e.g. (long)round(d) -> lround(d). */ /* If we're converting to char, we may encounter differing behavior between converting from double->char vs double->long->char. We're in "undefined" territory but we prefer to be conservative, so only proceed in "unsafe" math mode. */ if (optimize && (flag_unsafe_math_optimizations || (long_integer_type_node && outprec >= TYPE_PRECISION (long_integer_type_node)))) I think that we should not try to guarantee particular results for such out-of-range conversions (unspecified value plus "invalid" given Annex F, or undefined in the base standard). There are various known bugs in Bugzilla for cases where a single computation in the abstract machine that produces not-fully-specified results gets duplicated and the generated code ends up executing both duplicates, with different results from both, while other parts of the code expect the single computation in the abstract machine to have a single result, so assume the two values generated are the same when they are not. But I wouldn't expect those bugs to be addressed by guaranteeing that a given result, maybe matching hardware, is given globally from any such computation; it would seem more likely to address them by somehow preventing a single computation in the abstract machine from producing multiple different results in the actual execution, when it's a computation (such as a possibly out-of-range floating conversion to integer) for which the results are not fully specified. -- Joseph S. Myers joseph@codesourcery.com