From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 47CB03871D09; Fri, 16 Dec 2022 00:09:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 47CB03871D09 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BFNqW50005785; Fri, 16 Dec 2022 00:09:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=xn4gSBOP5/U3tiKcsvvhxMfmLLzlyr1wSmVAwODLQ/0=; b=d0wbeQtnuUVk1Uqmk+Dttal3prZmxswi8Jx+CLwmp8cMpBmg//0F5mHKPknztkso16CC mtH0G+YA4Cz2UEjOFa4CXYskWVKU7s3OJu9BjiAqVKj8vKOK1Sw/yayFDV4MbMQ51jte a0vtMczpXGB3ou2iDRJVD/oEpW9c4+g0y4WuFq9iVi8Oh9FEuD6XW1imH/Ys1K1nvZQR Gd1gp6KxczBslpBylbIHyq5JwLk6GZpN2ml/F3GQNhj/a/4OCuyvkmvoYSpakxktEWa8 xPOjMuj6/l/kuN6KKolUePGO3Udd4MYkP+lD7ax5QXsbf/0PeIRSG8yLflMZhdvNpltt JQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mgdmy0bcy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Dec 2022 00:09:44 +0000 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BFNuAKG015895; Fri, 16 Dec 2022 00:09:44 GMT Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mgdmy0bcm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Dec 2022 00:09:44 +0000 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BFME4rh005694; Fri, 16 Dec 2022 00:09:43 GMT Received: from smtprelay02.wdc07v.mail.ibm.com ([9.208.129.120]) by ppma03dal.us.ibm.com (PPS) with ESMTPS id 3meyfe279e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Dec 2022 00:09:43 +0000 Received: from smtpav01.dal12v.mail.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay02.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BG09frO983688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 16 Dec 2022 00:09:41 GMT Received: from smtpav01.dal12v.mail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 02AF758057; Fri, 16 Dec 2022 00:09:41 +0000 (GMT) Received: from smtpav01.dal12v.mail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4330358061; Fri, 16 Dec 2022 00:09:40 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.42.232]) by smtpav01.dal12v.mail.com (Postfix) with ESMTPS; Fri, 16 Dec 2022 00:09:40 +0000 (GMT) Date: Thu, 15 Dec 2022 19:09:38 -0500 From: Michael Meissner To: Segher Boessenkool Cc: Jakub Jelinek , "Kewen.Lin" , Michael Meissner , gcc-patches@gcc.gnu.org, Peter Bergner , David Edelsohn , Will Schmidt , William Seurer , Joseph Myers Subject: Re: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299 Message-ID: Mail-Followup-To: Michael Meissner , Segher Boessenkool , Jakub Jelinek , "Kewen.Lin" , gcc-patches@gcc.gnu.org, Peter Bergner , David Edelsohn , Will Schmidt , William Seurer , Joseph Myers References: <6b7325c6-6416-d64f-89a8-7341aeb8226c@linux.ibm.com> <20221215175949.GV25951@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221215175949.GV25951@gate.crashing.org> X-TM-AS-GCONF: 00 X-Proofpoint-GUID: khGAXOZJHYDtxq8-fcWW70hRixmJu5Un X-Proofpoint-ORIG-GUID: 0RxgOkl9IyWGiVMXAM6O9H7xBySY7zeC X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-15_12,2022-12-15_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=758 clxscore=1011 bulkscore=0 impostorscore=0 spamscore=0 malwarescore=0 lowpriorityscore=0 priorityscore=1501 adultscore=0 mlxscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212150200 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,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 Thu, Dec 15, 2022 at 11:59:49AM -0600, Segher Boessenkool wrote: > Hi! > > On Wed, Dec 14, 2022 at 10:36:03AM +0100, Jakub Jelinek wrote: > > On Wed, Dec 14, 2022 at 04:46:07PM +0800, Kewen.Lin via Gcc-patches wrote: > > > Since function useless_type_conversion_p considers two float types are compatible > > > if they have the same mode, so it doesn't require the explicit conversions between > > > these two types. I think it's exactly what we want. And to me, it looks unexpected > > > to have two types with the same mode but different precision. > > > > > > So could we consider disabling the above workaround to make _Float128 have the same > > > precision as __float128 (long double) (the underlying TFmode)? I tried the below > > > change: > > > > The hacks with different precisions of powerpc 128-bit floating types are > > very unfortunate, it is I assume because the middle-end asserted that scalar > > floating point types with different modes have different precision. > > IEEE QP and double-double cannot be ordered, neither represents a subset > of the other. But the current middle end does require a total ordering > for all floating point types (that can be converted to each other). > > Mike's precision hack was supposed to give us some time until an actual > fix was made. But no one has worked on that, and there have been > failures found with the precision hack as well, it worked remarkably > well but it isn't perfect. > > We cannot move forward in a meaningful way until these problems are > fixed. We can move around like headless chickens some more of course. In general I tend to think most of these automatic widenings are problematical. But there are cases where it makes sense. Lets see. On the PowerPC, there is no support for 32-bit decimal arithmetic. There you definately the compiler to automatically promoto SDmode to DDmode to do the arithmetic and then possibly convert it back. Similarly for the limited 16-bit floating point modes, where you have operations to pack and unpack the object, but you have no arithmetic. But I would argue that you NEVER want to automatically promoto DFmode to either KFmode, TFmode, or IFmode, since those modes are (almost) always going to be slower than doing the emulation. This is particularly true if we only support a subset of operations, where some things can be done inline, but a lot of operations would need to be done via emulation (such as on power8 where we don't have IEEE 128-bit support in hardware). If the machine independent part of the compiler decides oh we can do this operation because some operations are present (such as move, negate, absolute value, and compare), then you likely will wind up promoting the 64-bit type(s) to 128-bit, doing a call to a slower 128-bit function, and then truncating the value back to 64-bit is faster than calling a 64-bit emulation function. And even if the operation is does have a named insn to do the operation, it doesn't mean that you want to use that operation in general. I recall in the past that for some x86 boxes, the 80-bit XFmode insns floating point stack operations on the x86 were really slow compared to the current SFmode and DFmode SSE operations. But for some of the older machines, it may have been faster. And chosing a different -march= would change whether or not you want to do the optimization. Having these tables built statically can be a recipie for disaster. For floating point at least, I would prefer if a target had an option to dispense with the statically built get_wider tables, and did everything via target hooks. While for the PowerPC, we want to control what is the logical wider type for floating point types, I can imagine we don't want all backends to have to implment these hooks if they just have the standard 2-3 floating point modes. I purposelly haven't been looking into 16-bit floating point support, but I have to imagine there you have the problem that there are at least 2-3 different 16-bit formats roaming around. This is essentially the same issue in the PowerPC where you have 2 128-bit floating point types, neither of which is a pure subset of the other. To my way of thinking, it is a many branching tree. On the PowerPC, you want SDmode to promoto to DDmode, and possibly to TDmode. And SFmode mode would promote to DFmode, but DFmode would not generally promote automtically to IFmode, TFmode, or KFmode. We don't have any machines that support it, but I lets say some machine wanted to support both decimal types (DFP and BID). You would logically not want any DFP type to promoto to a BID type or vice versa. Sure, explicit conversions would be allowed, but not the invisibile conversions done to promote the type. In terms of these machine dependent types, there are some issues that show up when a port creates these special types. 1) It would be nice if _Complex worked with MD types. It is tiresome to have to use attribute((mode(...))) to get access to the complex variant of the type. 2) It would be nice the machine back end could define its own set of suffixes for floating point constants. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com