From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80177 invoked by alias); 3 Oct 2017 01:19:30 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 80166 invoked by uid 89); 3 Oct 2017 01:19:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=relate X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Oct 2017 01:19:28 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1dzBrm-0003pa-Ng from joseph_myers@mentor.com ; Mon, 02 Oct 2017 18:19:22 -0700 Received: from digraph.polyomino.org.uk (137.202.0.87) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 3 Oct 2017 02:19:19 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1dzBrg-00054u-2b; Tue, 03 Oct 2017 01:19:16 +0000 Date: Tue, 03 Oct 2017 01:19:00 -0000 From: Joseph Myers To: Michael Meissner CC: Segher Boessenkool , Richard Biener , Jakub Jelinek , Jason Merrill , Richard Earnshaw , "David S. Miller" , Bernd Schmidt , Ian Lance Taylor , Jim Wilson , GCC Patches , David Edelsohn , Bill Schmidt Subject: Re: [PATCH #2], Define __FP_FAST_FMAF128 on PowerPC ISA 3.0 In-Reply-To: <20171002235250.GA21210@ibm-tiger.the-meissners.org> Message-ID: References: <20170927221818.GA20589@ibm-tiger.the-meissners.org> <20171002235100.GA15723@ibm-tiger.the-meissners.org> <20171002235250.GA21210@ibm-tiger.the-meissners.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-10/txt/msg00102.txt.bz2 On Mon, 2 Oct 2017, Michael Meissner wrote: > > > But in any case, the new macro should be documented in cpp.texi alongside > > > the existing __FP_FAST_FMA* macros (probably in the generic > > > __FP_FAST_FMAF@var{n} and __FP_FAST_FMAF@var{n}X form). > > > > This patch adds support for adding the built-in __builtin_fmaf and > > __builtin_fmafx functions if the target machine supports an appropriate > > fused multiply-add (FMA) instruction. This patch replaces the original PowerPC > > specific patch. Certainly the FP_FAST_FMA* macros are supposed to relate to whether the public functions such as fmaf128 are fast rather than to __builtin_* names. I think there's a strong case that you should provide built-in functions under the public names when defining __FP_FAST_FMA*. I.e., add a variant of DEF_GCC_FLOATN_NX_BUILTINS that uses DEF_EXT_LIB_BUILTIN instead of DEF_GCC_BUILTIN, and use that for the new built-in functions. Then, the built-in functions, in whatever form they are provided, should be documented in extend.texi, alongside the documentation of __builtin_fabsf@var{n} etc. (with, of course, the caveats about availability when appropriate instruction support isn't available - the __builtin_fabsfN, __builtin_copysignfN functions are always inlined, the fma ones aren't, and people may well lack C library support for the underlying functions). Given that, I don't think the warning about lack of instruction support is appropriate; a call to __builtin_fmaf128, if the type is supported but there is no corresponding instruction (on x86_64, say), would just fall back to calling an external fmaf128 function (which in that case would work with glibc 2.26 or later, though calls to fmaf64 etc. wouldn't), much like any other such built-in function (we don't warn about e.g. calling __builtin_clog10 on systems whose C library may not have clog10). -- Joseph S. Myers joseph@codesourcery.com