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 7209E385840D for ; Mon, 18 Oct 2021 15:55:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7209E385840D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 5SVKUOMY0aOOVnSaOfaPeXiosEe7DVALGizykFnKLnFRJOA4Wra7hNJ/Ej9wk2vkG0qPi/AIkU lwVS8FNgAVow7yYtGN4LMqvrIueg+eBg4Mf9OMLxVawm7LzwuNVvT/aJ1nhy9el2Ig5tzRKxYd 9YXWn5Grj5Z4fmO8w88Xc4liXzvbPVvVJrnMrY8xsZWp2nmMqrqIhETcQ8IGqO7I2zG0VAc0W6 k6f1e21MOZpjiyOwXBVLFRX+ExvQ3CS7JjFNxtYQ4K1L9vqn8mHmJJq9aM1cUzH8zPjOCFXp/h oReEjr06O7ToBymc50OgL3Pv X-IronPort-AV: E=Sophos;i="5.85,382,1624348800"; d="scan'208";a="69790963" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 18 Oct 2021 07:55:00 -0800 IronPort-SDR: rVOUpg8PKXv1vMwx9wA6ay+o43N+BzibEQi6bSlZWghm+mrRffRd597QPDKunp9qw0kSNRZc3L iT7ZoT2GVWfOaBlvIJP39iD0i0dKgwG74AiYubvqS3cMLAq3/dad4e7M3Uc1YyivxVTMaVmC4i h2V2/8dpZ09eFS8N24q7EHsxqkJP1jsDAUn5sAAJih7N1xGWh22u/O1Fe56yJREImwrZMkVjGn qW6zoWKqGaRVS1dATINinr6IkrBEyTEShpTpW8QIVW7gS2NXy8YJbCK+xdcZR1hh8NAlWlsU8W X9c= Date: Mon, 18 Oct 2021 15:54:53 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Raoni Fassina Firmino CC: , , , , , , Subject: Re: [PATCH v6] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193] In-Reply-To: <20211017000415.vqt5yyrq7j7kg5c4@work-tp> Message-ID: References: <20211017000415.vqt5yyrq7j7kg5c4@work-tp> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3117.6 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2021 15:55:03 -0000 On Sun, 17 Oct 2021, Raoni Fassina Firmino wrote: > First is the different arguments from the C99 functions. I think the > solution is a macro to correct this, like so: > > #define feclearexcept(excepts) \ > __builtin_feclearexcept(excepts, FE_DIVBYZERO, FE_INEXACT, \ > FE_INVALID, FE_OVERFLOW, FE_UNDERFLOW) > > That is automatically always included or included when fenv.h is > included. Does the preprocessor have this ability? If so, where > should I put it? The compiler should not be adding such macros to libc headers. If libc wants to provide such optimizations based on built-in functions, they should go in libc headers with an appropriate condition on the compiler version. However, it's better to get things right automatically without needing any macros or other header additions at all. That is, define feclearexcept as a built-in function, *without* the extra arguments, and with the back end knowing about the FE_* values for the target libc. Then you can simply avoid expanding the function inline when the back end doesn't know both the FE_* values and how to use them. fpclassify is a fundamentally different case, because that's defined by the standard to be a *type-generic macro*, whereas feclearexcept is defined by the standard to be a *function*. The example of fpclassify should not be followed for feclearexcept, feraiseexcept or fegetround. > Second is the fallback of the expanders. When the expanders fail it > will leave the function call, which is great, but since the argument > list is different, well, it not is pretty. There is no execution If you define __builtin_X to have different arguments to X, it should also be defined so it's *always* expanded inline (on all architectures) and never falls back to a library function call to X. (This means, for example, not defining __builtin_X at all as a built-in function in cases, such as soft float, where you can't expand it inline, so that erroneous code trying to call __builtin_X in that case ends up with an undefined reference to the __builtin_X symbol.) Once you avoid having different arguments to the library function, you can simply avoid expanding inline whenever the back end lacks the relevant information; you don't need to do anything to avoid the built-in function existing. > +@deftypefn {Built-in Function} int __builtin_fegetround (int, int, int, int) > +This built-in implements the C99 fegetround functionality. The four int > +arguments should be the target library's notion of the possible FP rouding > +modes. They must be constant values and they must appear in this order: > +@code{FE_DOWNWARD}, @code{FE_TONEAREST}, @code{FE_TOWARDZERO}, > +@code{FE_UPWARD}. In other words: Some architectures have more rounding modes (e.g. FE_TONEARESTFROMZERO). Some have fewer. I think that illustrates the essential flaw of defining these functions to take a fixed set of rounding mode macros as arguments. On the other hand, there is a use for a *different* built-in function to get the rounding mode for FLT_ROUNDS, using the fixed set of values for FLT_ROUNDS specified in the C standard, and *always expanding inline without ever introducing a dependency on libm*. See bug 30569 and regarding that. -- Joseph S. Myers joseph@codesourcery.com