From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 00F97385840E for ; Mon, 31 Oct 2022 22:35:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 00F97385840E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.95,229,1661846400"; d="scan'208";a="85927476" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 31 Oct 2022 14:35:05 -0800 IronPort-SDR: cxKlvO8GazZV/aANsFzQ50rx6JcxnisZjcCIW1eKxM17DloVammtdaUrTp1133kLC4lX8vb4tw W5/xjKsBsuUjoCMB3viJUzLE4sUR39rEir64LBWpXJkv22jBT0rDFluqzmjhJvwsa2/DRsL3j7 DKWfM4SF54iQbxutb1jaLmF3m2jnHIvTah9Lkq6F4oJHUdRzJzmfVrQ1n6ia+kzcsf/+LE2FLA PkADTZzk0wZhvy5PnjPk9ATRNVIsyr9igMpN6/uP5z9jC2/jZDwvqYLmQHbj19ld4ZFJVpuRUd gz8= Date: Mon, 31 Oct 2022 22:35:00 +0000 From: Joseph Myers To: FX CC: Jakub Jelinek , Subject: Re: [PATCH] Add __builtin_iseqsig() In-Reply-To: <076BA73D-2FFC-4DEA-8BFA-B4D966F80F1D@gmail.com> Message-ID: References: <127A04DF-0BC1-40B4-956A-B22C39F97BF9@gmail.com> <3FD18835-D09C-4073-B23F-DD1038D4D0AC@gmail.com> <46e27067-6cb9-a5fc-f96-394515bcf9d@codesourcery.com> <076BA73D-2FFC-4DEA-8BFA-B4D966F80F1D@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3110.3 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP 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 Mon, 31 Oct 2022, FX via Gcc-patches wrote: > - rounded conversions: converting, from an integer or floating point > type, into another floating point type, with specific rounding mode > passed as argument These don't have standard C names. The way to do these in C would be using the FENV_ROUND pragma around a conversion, but we don't support any of the standard pragmas including those from C99 and they would be a large project (cf. Marc Glisse's -ffenv-access patches from August 2020 - although some things in FENV_ACCESS are probably rather orthogonal to FENV_ROUND, I expect what's required in terms of preventing unwanted code movement across rounding mode changes is similar). It might be possible to add built-in functions for such conversions without needing the FENV_ROUND machinery, if you make them expand to insn patterns (with temporary rounding mode changes) that are arranged so the compiler can't split them up. (There's a principle of not introducing libm dependencies in code not using any , or functions or corresponding built-in functions, which would be an issue for generating calls to fesetround, inline or in libgcc, from such an operation. But arguably, even if FENV_ROUND shouldn't introduce such dependencies - my assumption being that FENV_ROUND should involve target-specific inline implementations of the required rounding mode changes - it might be OK to document some GCC-specific built-in function as doing so.) > - conversion to integer: converting, from a floating point type, into an > integer type, with specific rounding mode passed as argument See the fromfp functions (signed and unsigned versions, versions with and without raising inexact, rounding mode specified as one of the FP_INT_* macros from ). The versions in TS 18661-1 produced results in an integer type (intmax_t / uintmax_t, with the actual width for the conversion passed as an argument). *But* C2X changed that to return the result in a floating-point type instead (as part of reducing the use of intmax_t in interfaces) - I haven't yet implemented that change in glibc. So the way to do such a conversion to an integer type in C2X involves calling such a function and then converting its result to that integer type. GCC certainly knows about handling such a pair ( function, conversion of its result) as a built-in function (e.g. __builtin_iceil). My guess is that in most cases only selected calls would be expanded inline - calls where not only is there an appropriate conversion to an integer type (matching, or maybe wider than, the width passed to the function), but where also the function, rounding mode and width together match an operation for which there is a hardware instruction, with other cases (including ones where the rounding mode or width aren't constant) ending up as runtime calls (unless optimized for constant arguments). So while the interfaces exist in C2X, the built-in function support in GCC may be fairly complicated, with the existence of the older TS 18661-1 version of the functions complicating things further. > - IEEE operations corresponding to nextDown and nextUp (or are those > already available? I have not checked the fine print) nextdown and nextup have been in glibc since version 2.24. I expect that adding built-in functions that optimize them for constant arguments would be straightforward (that doesn't help if what you actually want it some way to support those operations at runtime for targets without the functions in libm, of course). -- Joseph S. Myers joseph@codesourcery.com