From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 0BA193857C4F for ; Fri, 11 Dec 2020 22:07:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0BA193857C4F Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0BBM77sL187428; Fri, 11 Dec 2020 17:07:33 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 35cg4k9f13-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Dec 2020 17:07:33 -0500 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0BBM7WoS188524; Fri, 11 Dec 2020 17:07:33 -0500 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 35cg4k9f0x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Dec 2020 17:07:32 -0500 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 0BBLmhIe031584; Fri, 11 Dec 2020 22:07:32 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma03dal.us.ibm.com with ESMTP id 3581ua7feb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Dec 2020 22:07:32 +0000 Received: from b03ledav006.gho.boulder.ibm.com (b03ledav006.gho.boulder.ibm.com [9.17.130.237]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 0BBM7UVf25166312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 Dec 2020 22:07:30 GMT Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8BB90C654A; Fri, 11 Dec 2020 22:07:30 +0000 (GMT) Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E6779C6548; Fri, 11 Dec 2020 22:07:29 +0000 (GMT) Received: from ibm-toto.the-meissners.org (unknown [9.160.117.152]) by b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTPS; Fri, 11 Dec 2020 22:07:29 +0000 (GMT) Date: Fri, 11 Dec 2020 17:07:28 -0500 From: Michael Meissner To: Segher Boessenkool Cc: Michael Meissner , gcc-patches@gcc.gnu.org, David Edelsohn , Bill Schmidt , Peter Bergner Subject: Re: [PATCH] PowerPC: Map IEEE 128-bit long double built-in functions Message-ID: <20201211220728.GA25584@ibm-toto.the-meissners.org> Mail-Followup-To: Michael Meissner , Segher Boessenkool , gcc-patches@gcc.gnu.org, David Edelsohn , Bill Schmidt , Peter Bergner References: <20201119235814.GA322@ibm-toto.the-meissners.org> <20201210212001.GW2672@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201210212001.GW2672@gate.crashing.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-11_06:2020-12-11, 2020-12-11 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 impostorscore=0 suspectscore=0 phishscore=0 mlxscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012110142 X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 22:07:36 -0000 On Thu, Dec 10, 2020 at 03:20:01PM -0600, Segher Boessenkool wrote: > Hi! > > On Thu, Nov 19, 2020 at 06:58:14PM -0500, Michael Meissner wrote: > > * config/rs6000/rs6000.c (rs6000_mangle_decl_assembler_name): Add > > support for mapping built-in function names for long double > > built-in functions if long double is IEEE 128-bit. > > Please write what it does, not "add support". Say what names it maps > to, importantly. You don't need to list all, but what you wrote is > 100% contentless. Ok. > > diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c > > index a5188553593..35e9c844e17 100644 > > --- a/gcc/config/rs6000/rs6000.c > > +++ b/gcc/config/rs6000/rs6000.c > > @@ -27065,57 +27065,128 @@ rs6000_globalize_decl_name (FILE * stream, tree decl) > > library before you can switch the real*16 type at compile time. > > > > We use the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change this name. We > > - only do this if the default is that long double is IBM extended double, and > > - the user asked for IEEE 128-bit. */ > > + only do this transformation if the __float128 type is enabled. This > > + prevents us from doing the transformation on older 32-bit ports that might > > + have enabled using IEEE 128-bit floating point as the default long double > > + type. */ > > I still don't understand why you want to support some hypothetical and > untested configuration. I'm not sure what you mean by hypothetical and untested configuration. If you build a default configuration on a big endian system (i.e. do not use --with-cpu specifying at least power7), the __float128 type is not enabled by default, because you need access to the VSX vector registers. > > + /* { dg-final { scan-assembler {\mbl __ynieee128} } } */ > > This kind of thing does not portably work (the function names can have > various prefixes added). Why would it have prefixes? Can you suggest a better way of doing the test? There are lots of different long names that need to get mapped if long doubles are IEEE 128-bit. This test just tries to test every function to make sure it got mapped appropriately. We can't do a link test without requiring that GLIBC is 2.32 or newer, since the older GLIBCs don't have all of the symbols. And the link test would only work on little endian ELFV2 systems, since big endian GLIBC 2.32 does not export any of the float128 stuff. > I cannot understand this code, and it does seem far from obviously > correct. But, okay for trunk if you handle all fallout (and I mean all, > not just "all you consider important"). Note, the code is only invokved for systems where IEEE 128-bit floating point is supported. So it will never get called for a lot of the random embedded systems or the big endian systems. There is another way I could do the code that is simpler, but over time it will need maintainence as new built-in functions are added. Right now, in going over the system built-ins, it tries to do the mapping based on the names: 1) If the function has a long double argument or returns long double, and it ends in 'l', the name is mapped to "__" followed by and then "ieee128". I.e. "sinl" becomes "__sinieee128". 2) However, some names do not follow that formula and I have a switch statement for the outliers. 3) If the function name ends in "printf", the name is transformed to "__" followed by followed by "ieee128". I.e. "sprintf" becomes "__sprintfieee128". 4) If the function names ends in "scanf", the name is transformed to "__isoc99_" followed by followed by "ieee128". I.e. "vscanf" becomes "__isoc99_vscanfieee128". I could change it to just having a switch statement of all known built-in functions. I would need to add some code that if checking was enabled, it would look for built-in functions that use long double that are not mapped, and issue a warning to update the table of maps. This might be cleaner to look at, but every so often, we would need to add a new symbol. Would you prefer me to do that second implementation? -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.ibm.com, phone: +1 (978) 899-4797