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 95EF6384D6DA; Fri, 16 Dec 2022 21:53:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 95EF6384D6DA 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 (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BGLfl7q018615; Fri, 16 Dec 2022 21:53:40 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=Uo10X/A0j5ARGtNORC/+2uANxm5/p31LGO+BqjC13CM=; b=pzimKpmf+nH4k/u5m3pa/masrFmN+P9XcjxHu/mPV7Y6EfG/qqx5EatpLAqYOFpXpO21 ChZauxsF6le58NtSGvlFCAEfPTmX9NLmFpvE+mZSIrqIGZMZom5dhJoJU8p/5/kcyple U9u+1y3oDKX+8i2UkLiQ0ehiHrA06XM6/n9QpntXl8uC87J/k3vV45LRZedFuSxuFcEZ /HuM/vlIYV67O3x0mDTEMxTT+6dqJovGi+ch/MlArRANYrQlqFFihjmn4ye98Ph1ruY7 Bzw/iEKKJwjVKPgNY11BIK4wwRjO/tF7qlITZa+QNnu06D2Gy2vs1fbIlBCn0YBfSlnH 9g== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mh0tgr8kd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Dec 2022 21:53:39 +0000 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BGLgkjF025399; Fri, 16 Dec 2022 21:53:39 GMT Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mh0tgr8js-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Dec 2022 21:53:39 +0000 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BGKtgZR030922; Fri, 16 Dec 2022 21:53:38 GMT Received: from smtprelay01.wdc07v.mail.ibm.com ([9.208.129.119]) by ppma04wdc.us.ibm.com (PPS) with ESMTPS id 3meyqkvqvn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Dec 2022 21:53:38 +0000 Received: from smtpav04.wdc07v.mail.ibm.com (smtpav04.wdc07v.mail.ibm.com [10.39.53.231]) by smtprelay01.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BGLraMo35848666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 16 Dec 2022 21:53:36 GMT Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 74F6658052; Fri, 16 Dec 2022 21:53:36 +0000 (GMT) Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 70C7558050; Fri, 16 Dec 2022 21:53:35 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.42.232]) by smtpav04.wdc07v.mail.ibm.com (Postfix) with ESMTPS; Fri, 16 Dec 2022 21:53:35 +0000 (GMT) Date: Fri, 16 Dec 2022 16:53:33 -0500 From: Michael Meissner To: Segher Boessenkool Cc: Michael Meissner , Jakub Jelinek , "Kewen.Lin" , 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> <20221216175527.GB25951@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221216175527.GB25951@gate.crashing.org> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 2g3pMOVUbcpU8m1ABUM_oMgKhwhljJoN X-Proofpoint-GUID: vC3LEWTGE4jrTEEeZlaGjM8szsFJU7Oj 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-16_14,2022-12-15_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxlogscore=748 lowpriorityscore=0 mlxscore=0 phishscore=0 suspectscore=0 bulkscore=0 adultscore=0 spamscore=0 impostorscore=0 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212160192 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 Fri, Dec 16, 2022 at 11:55:27AM -0600, Segher Boessenkool wrote: > Hi! > > On Thu, Dec 15, 2022 at 07:09:38PM -0500, Michael Meissner wrote: > > On Thu, Dec 15, 2022 at 11:59:49AM -0600, Segher Boessenkool wrote: > > > On Wed, Dec 14, 2022 at 10:36:03AM +0100, Jakub Jelinek wrote: > > > > 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. > > These things are *not* widening at all, that is the problem. For some > values it is lossy, in either direction. Ummm yes and no. Going from SFmode to DFmode is a widening, as is SDmode to DDmode. Since all values within SFmode or SDmode can be represented in DFmode/DDmode. That is needed, since not all machines have full support for arithmetic. Going from DFmode to KFmode is still a widening, but in general we may want to prevent it from happing due to the speed of KFmode operations compared to DFmode. Likewise going from DFmode to IFmode is a widening since all values in DFmode can be represented in IFmode. Obviously going from IFmode to KFmode or the reverse is where the issue it. > > 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. > > And those things *are* widening, non-lossy in all cases. Well-defined > etc. Yes, but we just need to improve the hooks to prevent cases where it is not defined. > > 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). > > TFmode is either the same actual mode as either KFmode or IFmode, let's > reduce confusion by not talking about it at all anymore. > > The middle end should never convert to another mode without a good > reason for it. But OTOH, both IFmode and KFmode can represent all > values in DFmode, you just have to be careful about semantics when > eventually converting back. It doesn't. Where the issue is is when you call a built-in function and that built-in function uses different types than what you pass. Then conversions have to be inserted. > > 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. > > This does not in general have the correct semantics though (without > -ffast-math), so the compiler will not do things like it. It would happen if we didn't set the hooks to prevent it, but we did. Maybe there are places that need more 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. > > KFmode is not wider than IFmode. IFmode is not wider than KFmode. > KFmode can represent values IFmode cannot. IFmode can represent valuse > KFmode cannot. There the issue is the historical issue that GCC believes there is only number (precision) that says whether one type is wider than another. And to some extent, precision is wrong, in that do you want precision to mean the number of bytes in a value, the mantissa size, the exponent size, or whether special cases matter. > > 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. > > There are at least six 16-bit float formats in actual use. But we care > mostly about IEEE binary16 and about bfloat16, each with or without > non-normal values (and the encodings for those reused for extra normal > numbers, perhaps). You and I may only care about those two types. Other port maintainers may need to consider any of the other variants. > > To my way of thinking, it is a many branching tree. On the PowerPC, you want > > SDmode to promoto to DDmode, > > But it is the backend that should be in control there, not generic code. > And that is the way things already work! No that is not the way things work. The way the types are laid out, it demands that each precision is unique with the class of binary vs. decimal. And that without hooks, that for any floating point type, you can ask for a wider precision, and it will give it to you. If we didn't have the requirement that there only be one type per precision then things would be simpler. We would need some way of going to the wider type rather than the pre-built tables we currently. > > and possibly to TDmode. And SFmode mode would > > promote to DFmode, > > In general we do not, it would not have the correct semantics. When you combine two types in a binary operator and the types are different, you have to either convert one side to the other type, or you have to convert both sides to a common type. > Anyway, to get us back on track a bit: > > There should not be any non-explicit conversions from KFmode to IFmode > or vice versa. Each of those modes can represent values the other can > not. There is no ordering between those modes in that sense, we should > not pretend there is one. And we have already prevented that (subject to places that were missed). But when a built-in is called with another type, it forces conversions to be done. In the specific cases, since currently GCC uses different internal types for __float128 and _Float128 in the case long doubles are IEEE 128-bit, if for instance, you have a __float128 type and you assign it the __builtin_nanq function that involves a conversion from the _Float128 type to __float128. In the case where long double is IBM double double or just double, then __float128 and _Float128 are the same internal type, and no conversion is done. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com