From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91037 invoked by alias); 21 Jun 2016 20:53:34 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 91017 invoked by uid 89); 21 Jun 2016 20:53:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=narrower, sk:fexcess, infinities, __float80 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 21 Jun 2016 20:53:20 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u5LKmvOt110649 for ; Tue, 21 Jun 2016 16:53:18 -0400 Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by mx0a-001b2d01.pphosted.com with ESMTP id 23qaedvwgh-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Jun 2016 16:53:18 -0400 Received: from localhost by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 21 Jun 2016 14:53:17 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 21 Jun 2016 14:53:12 -0600 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: meissner@ibm-tiger.the-meissners.org Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 5275F3E40030; Tue, 21 Jun 2016 14:53:12 -0600 (MDT) Received: from b03ledav005.gho.boulder.ibm.com (b03ledav005.gho.boulder.ibm.com [9.17.130.236]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u5LKrCOS47120522; Tue, 21 Jun 2016 13:53:12 -0700 Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2749FBE039; Tue, 21 Jun 2016 14:53:12 -0600 (MDT) Received: from ibm-tiger.the-meissners.org (unknown [9.32.77.111]) by b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTP id C90DDBE03A; Tue, 21 Jun 2016 14:53:11 -0600 (MDT) Received: by ibm-tiger.the-meissners.org (Postfix, from userid 500) id C718045CFA; Tue, 21 Jun 2016 16:53:02 -0400 (EDT) Date: Tue, 21 Jun 2016 20:53:00 -0000 From: Michael Meissner To: Joseph Myers Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, jason@redhat.com, richard.earnshaw@arm.com, nickc@redhat.com, ramana.radhakrishnan@arm.com, marcus.shawcroft@arm.com, dje.gcc@gmail.com, segher@kernel.crashing.org, meissner@linux.vnet.ibm.com, murphyp@linux.vnet.ibm.com, bje@gnu.org, Bill Schmidt , Steve Munroe Subject: Re: Implement C _FloatN, _FloatNx types [version 2] Mail-Followup-To: Michael Meissner , Joseph Myers , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, jason@redhat.com, richard.earnshaw@arm.com, nickc@redhat.com, ramana.radhakrishnan@arm.com, marcus.shawcroft@arm.com, dje.gcc@gmail.com, segher@kernel.crashing.org, murphyp@linux.vnet.ibm.com, bje@gnu.org, Bill Schmidt , Steve Munroe References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16062120-0024-0000-0000-000013F1DC46 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16062120-0025-0000-0000-000042050D66 Message-Id: <20160621205302.GA8544@ibm-tiger.the-meissners.org> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-21_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606210230 X-SW-Source: 2016-06/txt/msg00078.txt.bz2 On Tue, Jun 21, 2016 at 05:41:36PM +0000, Joseph Myers wrote: > [Changes in version 2 of the patch: > > * PowerPC always uses KFmode for _Float128 and _Float64x when those > types are supported, not TFmode. While from one perspective, it would have been cleaner if the PowerPC had separate internal types for IBM extended double and IEEE 128-bit floating point. But the way the compiler has been implemented is that TFmode is which ever type is the default. Typically, in the Linux environment, this is IBM extended double, but we are hoping in the future to change the default to make long double IEEE 128-bit. So, I think we need to do something like: static machine_mode rs6000_floatn_mode (int n, bool extended) { if (extended) { switch (n) { case 32: return DFmode; case 64: if (TARGET_FLOAT128) return (TARGET_IEEEQUAD) ? TFmode : KFmode; else return VOIDmode; case 128: return VOIDmode; default: /* Those are the only valid _FloatNx types. */ gcc_unreachable (); } } else { switch (n) { case 32: return SFmode; case 64: return DFmode; case 128: if (TARGET_FLOAT128) return (TARGET_IEEEQUAD) ? TFmode : KFmode; else return VOIDmode; default: return VOIDmode; } } } As an aside, one of the issues, I'm currently grappling with is how to enable the __float128 machinery without enabling the __float128 keyword (PR 70589). The reason is we need to create the various built-in functions for IEEE 128-bit functions, which means creating the type and keyword support. As Richard Biener and I discussed, the way I created the types using FRACTIONAL_FLOAT_MODE for IFmode/KFmode isn't really ideal. https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01114.html It would have made things simpler if there was a MD hook to control what automatically widens to what. I tried to implement it in the early days, but I never came up with code that did what I wanted. I use rs6000_invalid_binary_op to do this to some extent. Another thing that I'm grappling with is how to identify when the floating point emulation functions have been built. Right now, it is only built for 64-bit Linux systems, and it is not built for AIX, BSD, or the various 32-bit embedded targets. > No GCC port supports a floating-point format suitable for _Float128x. > Although there is HFmode support for ARM and AArch64, use of that for > _Float16 is not enabled. Supporting _Float16 would require additional > work on the excess precision aspects of TS 18661-3: there are new > values of FLT_EVAL_METHOD, which are not currently supported in GCC, > and FLT_EVAL_METHOD == 0 now means that operations and constants on > types narrower than float are evaluated to the range and precision of > float. Implementing that, so that _Float16 gets evaluated with excess > range and precision, would involve changes to the excess precision > infrastructure so that the _Float16 case is enabled by default, unlike > the x87 case which is only enabled for -fexcess-precision=standard. > Other differences between _Float16 and __fp16 would also need to be > disentangled. ISA 3.0 (Power9) does have instructions to convert to/from 16-bit floating point to 32-bit floating point. Right now, it is just conversion to/from storage format to a more normal format (similar to _Decimal32 where there are no instructions to operate on 32-bit decimal data). At the moment, we don't have support for these instructions, but we will likely do it in the future. However, I suspect that in the future, we may have users that want to do arithmetic in this format (particularly vectors). This comes from people wanting to interface with attached GPUs that often times support HFmode, and with machine learning systems that does not need the precision. So, we should at least think what is needed to enable HFmode as a real type. > GCC has some prior support for nonstandard floating-point types in the > form of __float80 and __float128. Where these were previously types > distinct from long double, they are made by this patch into aliases > for _Float64x / _Float128 if those types have the required properties. And of course other machine dependent non-standard floating point types such as IBM extended double. In addition, there is the question of what to do on the embedded machines that might use IEEE format for floating point, but does not support all of the features in IEEE 754R such as NaNs, infinities, de-normal numbers, negative 0, etc. As I said in my previous message, what ever we do in this space needs to be backwards compatible with existing usage in GCC 6.x. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797