From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125754 invoked by alias); 5 Aug 2016 00:35:48 -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 125734 invoked by uid 89); 5 Aug 2016 00:35:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=adventure, extent, hundreds, H*Ad:U*bje X-Spam-User: qpsmtpd, 2 recipients 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 05 Aug 2016 00:35:37 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1bVT6s-0006Gd-5L from joseph_myers@mentor.com ; Thu, 04 Aug 2016 17:35:34 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.3.224.2; Fri, 5 Aug 2016 01:35:30 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1bVT6n-0003DG-Cq; Fri, 05 Aug 2016 00:35:29 +0000 Date: Fri, 05 Aug 2016 00:35:00 -0000 From: Joseph Myers To: Michael Meissner CC: , , , , , , , , , , Subject: Re: Implement C _FloatN, _FloatNx types In-Reply-To: <20160805000934.GA21406@ibm-tiger.the-meissners.org> Message-ID: References: <20160805000934.GA21406@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-SW-Source: 2016-08/txt/msg00405.txt.bz2 On Thu, 4 Aug 2016, Michael Meissner wrote: > It brings up a general complaint that I had when I started the whole PowerPC > __float128 adventure is that we have multiple places in the compiler it goes > through a list of floating point types, and only for the blessed types does it > do something. If a port happens to have a non-standard type, there really > should be target hooks for doing each of the actions. Note that not all the types / modes are necessarily suitable for all those places. Consider IA64 RFmode (__fpreg), for example. And some things such as macros aren't defined for nonstandard types. > But rather than having lots of different hooks, it may be better to have a hash > lookup given a type node (and/or mode) that registers all of the handling in a > central place, rather than continually having: In various places you need to get the right ordering of types, and to distinguish types for the same mode (e.g. usual arithmetic conversions have a specified ordering); it's not just a lookup table. This patch is explicitly not trying to improve anything for types that are *not* _FloatN / _FloatNx (such as __fp16, or __fpreg). For the _FloatN and _FloatNx types it tries to use the various macros for looping over those types as far as possible, not hardcoding a list of them in too many places. It is also explicitly aiming to get support for _FloatN / _FloatNx to a minimal functional state (conforming to the TS semantics, to the extent that the underlying arithmetic for the relevant machine modes does, and apart from the corner case of treating _FloatN as a keyword for arbitrary N >= 128 and a multiple of 32) that can be incrementally improved, rather than to make it fully equivalent to that for float, double and long double (which runs into issues with adding hundreds of new built-in functions, among other things) - that is, to be the smallest version of support for these types that would be appropriate for GCC, not the maximal version, in accordance with the principle of submitting minimal indivisible patches. The list of things not done in the notes for this patch is intended to be exhaustive as a list of potential future improvements for bringing these types to full parity with float, double and long double. -- Joseph S. Myers joseph@codesourcery.com