From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 448DE3858D33 for ; Wed, 22 Feb 2023 10:13:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 448DE3858D33 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 (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31M9o5mg024232; Wed, 22 Feb 2023 10:13:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : references : cc : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=LIRc6TMBroRn8dWW41OYAfRa6fJ1CB1xDbg3uCenYzI=; b=NOP6c4Xh8N0S9qyoc8QfnbdWLynSBhnErKh5JruiSuHTgwVu//xH4OPIn5oS3xzN+6Oi VYndAeXItxls2eIKCzOQFl7QB9hXRQl4wbFSdj8epK41XhEEgwnLLhrnROskHl1/Li7d 8yuZWPu9LxP6qresTQlXKwCSfdAZmycuBdobTxDw9zu7/Dn9qjHM4SOgcE4ywCT2Do8s V65PkiAH2sBVIBqDJ0X9+Ket9F7EuVQQxIbHw28PIFLzGG5PuiiTH7VwCMktqfO6kyp0 va9tHR4Xmn8ubWbqXj1fGMqXuYm7MobGkbnUIEQUkQZQXsKzMSJVnolM2bf8SJTb7qzZ /Q== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3nwgrr0jdu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 10:13:17 +0000 Received: from m0098416.ppops.net (m0098416.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 31M9qt5M002803; Wed, 22 Feb 2023 10:13:17 GMT Received: from ppma02fra.de.ibm.com (47.49.7a9f.ip4.static.sl-reverse.com [159.122.73.71]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3nwgrr0jdb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 10:13:17 +0000 Received: from pps.filterd (ppma02fra.de.ibm.com [127.0.0.1]) by ppma02fra.de.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 31MAANxL001647; Wed, 22 Feb 2023 10:13:15 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma02fra.de.ibm.com (PPS) with ESMTPS id 3ntpa63wue-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 10:13:15 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 31MADBaY29032840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Feb 2023 10:13:11 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8F61320075; Wed, 22 Feb 2023 10:13:11 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5330F20074; Wed, 22 Feb 2023 10:13:09 +0000 (GMT) Received: from [9.197.242.224] (unknown [9.197.242.224]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 22 Feb 2023 10:13:08 +0000 (GMT) Message-ID: Date: Wed, 22 Feb 2023 18:13:07 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH 2/2] Rework 128-bit complex multiply and divide. Content-Language: en-US To: Michael Meissner References: Cc: gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn , Peter Bergner , Will Schmidt From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: mwtscg9ZzgOuAA4IW-_iWWfmKmBsYgce X-Proofpoint-GUID: qJliYmHkiL6uLiWv6CpkNJhVwnHq_Cle X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-22_05,2023-02-22_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 impostorscore=0 mlxscore=0 adultscore=0 mlxlogscore=750 priorityscore=1501 spamscore=0 clxscore=1015 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302220087 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Mike, on 2023/2/3 13:53, Michael Meissner wrote: > This patch reworks how the complex multiply and divide built-in functions are > done. Previously we created built-in declarations for doing long double complex > multiply and divide when long double is IEEE 128-bit. The old code also did not > support __ibm128 complex multiply and divide if long double is IEEE 128-bit. > > This patch was originally posted on December 13th, 2022: > > | Date: Tue, 13 Dec 2022 01:21:06 -0500 > | Subject: [PATCH V2] Rework 128-bit complex multiply and divide, PR target/107299 > | Message-ID: > > In terms of history, I wrote the original code just as I was starting to test > GCC on systems where IEEE 128-bit long double was the default. At the time, we > had not yet started mangling the built-in function names as a way to bridge > going from a system with 128-bit IBM long double to 128-bin IEEE long double. > > The original code depends on there only being two 128-bit types invovled. With > the next patch in this series, this assumption will no longer be true. When > long double is IEEE 128-bit, there will be 2 IEEE 128-bit types (one for the > explicit __float128/_Float128 type and one for long double). > > The problem is we cannot create two separate built-in functions that resolve to > the same name. This is a requirement of add_builtin_function and the C front > end. That means for the 3 possible modes (IFmode, KFmode, and TFmode), you can > only use 2 of them. > > This code does not create the built-in declaration with the changed name. > Instead, it uses the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change the name > before it is written out to the assembler file like it now does for all of the > other long double built-in functions. > > When I wrote these patches, I discovered that __ibm128 complex multiply and > divide had originally not been supported if long double is IEEE 128-bit as it > would generate calls to __mulic3 and __divic3. I added tests in the testsuite > to verify that the correct name (i.e. __multc3 and __divtc3) is used in this > case. > > I had previously sent this patch out on November 1st. Compared to that version, > this version no longer disables the special mapping when you are building > libgcc, as it turns out we don't need it. > > I tested all 3 patchs for PR target/107299 on: > > 1) LE Power10 using --with-cpu=power10 --with-long-double-format=ieee > 2) LE Power10 using --with-cpu=power10 --with-long-double-format=ibm > 3) LE Power9 using --with-cpu=power9 --with-long-double-format=ibm > 4) BE Power8 using --with-cpu=power8 --with-long-double-format=ibm > > Once all 3 patches have been applied, we can once again build GCC when long > double is IEEE 128-bit. There were no other regressions with these patches. > Can I check these patches into the trunk? These two above paragraphs look a bit out of date (two patches now). :) IIUC this patch actually fixes a latent issue, so it is independent of the one fixing the bootstrapping issue, right? This updated version of patch looks good to me, but I'd leave the approval to Segher/David. Thanks! BR, Kewen