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 6B85A3850084; Thu, 8 Dec 2022 22:04:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6B85A3850084 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 (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2B8KQmCf033203; Thu, 8 Dec 2022 22:04:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : content-transfer-encoding : mime-version; s=pp1; bh=Mwi/6tKMKZE5jZcYFxgvRlY9EMA/I0lYRK+VV+6/I5M=; b=Lj6QwNs4DUtcHiftBHzMExUx4ScsQwFcVjNZzXkU5tu4/ipw/Nf106dvm/F5v1iaK8VX TJjSY/mtrIDZZZcFoew7VOY9RB9qYNilHpb2ouujQpZgFdw4i+UgMiIjM/hok8nFNb8U CEnkqdAI7lg/nNDhRTWrsT+gmuUFtFGtwqAjCVwbAQRbIGrF5W1hXkEp4V5zsZFLJ3vl Nwr6SRVlAkinu0vujvmT10UpPE8sSolmm9eRSRZNFm1+v0GFQ2GazXAEG154dcK7Osmx qw8u1NyUnbvjsCMcLn6kMbSNgw72y0mIGsnSAhLP8rUI2FRQjCFRpPN0cNeFYK5cWDfg 3A== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mbk0g09ta-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Dec 2022 22:04:12 +0000 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2B8LmrIr021800; Thu, 8 Dec 2022 22:04:12 GMT Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mbk0g09s7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Dec 2022 22:04:12 +0000 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2B8K63gm022248; Thu, 8 Dec 2022 22:04:10 GMT Received: from smtprelay02.dal12v.mail.ibm.com ([9.208.130.97]) by ppma01wdc.us.ibm.com (PPS) with ESMTPS id 3m9pqgkmg8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Dec 2022 22:04:10 +0000 Received: from smtpav06.dal12v.mail.ibm.com (smtpav06.dal12v.mail.ibm.com [10.241.53.105]) by smtprelay02.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2B8M49N745286092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 8 Dec 2022 22:04:09 GMT Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7F4AE5805D; Thu, 8 Dec 2022 22:04:09 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EC92258059; Thu, 8 Dec 2022 22:04:08 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.42.232]) by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTPS; Thu, 8 Dec 2022 22:04:08 +0000 (GMT) Date: Thu, 8 Dec 2022 17:04:07 -0500 From: Michael Meissner To: "Kewen.Lin" Cc: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn , Peter Bergner , William Seurer , Will Schmidt Subject: Re: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR target/107299 Message-ID: Mail-Followup-To: Michael Meissner , "Kewen.Lin" , gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn , Peter Bergner , William Seurer , Will Schmidt References: <997752a6-8cd4-abc5-d6e3-2e75eaa37d57@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-GUID: St_8c6BiwxIY_NVyyE5NvEd3owHSUBJI X-Proofpoint-ORIG-GUID: gPzSh6ZntKMUtVanNnu0E2q5zg1NHxSH Content-Transfer-Encoding: 8bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 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-08_11,2022-12-08_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 impostorscore=0 phishscore=0 mlxlogscore=681 malwarescore=0 suspectscore=0 mlxscore=0 clxscore=1015 adultscore=0 lowpriorityscore=0 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2212080184 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,WEIRD_PORT 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 Wed, Dec 07, 2022 at 03:55:41PM +0800, Kewen.Lin wrote: > Hi Mike, > > on 2022/12/7 14:44, Michael Meissner wrote: > > On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote: > >> Hi Mike, > >> > >> Thanks for fixing this! > >> > >> Could you help to elaborate why we need to disable it during libgcc building? > > > > When you are building libgcc, you are building the __mulkc3, __divkc3 > > functions. The mapping in the compiler interferes with those functions, > > because at the moment, libgcc uses an alternate IEEE 128-bit type. > > > > But I'm still confused. For __mulkc3 (__divkc3 is similar), > > 1) with -mabi=ieeelongdouble (TARGET_IEEEQUAD true, define __LONG_DOUBLE_IEEE128__), > the used types are: > > typedef float TFtype __attribute__ ((mode (TF))); > typedef __complex float TCtype __attribute__ ((mode (TC))); > > 2) with -mabi=ibmlongdouble (TARGET_IEEEQUAD false, not __LONG_DOUBLE_IEEE128__ defined), > the used types are: > > typedef float TFtype __attribute__ ((mode (KF))); > typedef __complex float TCtype __attribute__ ((mode (KC))); > > The proposed mapping in the current patch is: > > + > + if (id == complex_multiply_builtin_code (KCmode)) > + newname = "__mulkc3"; > + > + else if (id == complex_multiply_builtin_code (ICmode)) > + newname = "__multc3"; > + > + else if (id == complex_multiply_builtin_code (TCmode)) > + newname = (TARGET_IEEEQUAD) ? "__mulkc3" : "__multc3"; > > for 1), TCmode && TARGET_IEEEQUAD => "__mulkc3" > for 2), KCmode => "__mulkc3" > > Both should be still with name "__mulkc3", do I miss anything? > > BR, > Kewen The reason is due to the different internal types, the value range propigation pass throws an error when we are trying to build libgcc. This is due to the underlying problem of different IEEE 128-bit types within the compiler. The 128-bit IEEE support in libgcc was written before _Float128 was added to GCC. One consequence is that you can't get to the complex variant of __float128. So libgcc needs to use the attribute mode to get to that type. But with the support for IEEE 128-bit long double changing things, it makes the libgcc code use the wrong code. /home/meissner/fsf-src/work102/libgcc/config/rs6000/_mulkc3.c: In function ‘__mulkc3_sw’: /home/meissner/fsf-src/work102/libgcc/config/rs6000/_mulkc3.c:97:1: internal compiler error: in fold_stmt, at gimple-range-fold.cc:522 97 | } | ^ 0x122784f3 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&, tree_node*) /home/meissner/fsf-src/work102/gcc/gimple-range-fold.cc:522 0x1226477f gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*) /home/meissner/fsf-src/work102/gcc/gimple-range.cc:257 0x12264b1f gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*) /home/meissner/fsf-src/work102/gcc/gimple-range.cc:318 0x113bdd8b range_query::value_of_stmt(gimple*, tree_node*) /home/meissner/fsf-src/work102/gcc/value-query.cc:134 0x1134838f rvrp_folder::value_of_stmt(gimple*, tree_node*) /home/meissner/fsf-src/work102/gcc/tree-vrp.cc:1023 0x111344cf substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) /home/meissner/fsf-src/work102/gcc/tree-ssa-propagate.cc:819 0x121ecbd3 dom_walker::walk(basic_block_def*) /home/meissner/fsf-src/work102/gcc/domwalk.cc:311 0x11134ee7 substitute_and_fold_engine::substitute_and_fold(basic_block_def*) /home/meissner/fsf-src/work102/gcc/tree-ssa-propagate.cc:998 0x11346bb7 execute_ranger_vrp(function*, bool, bool) /home/meissner/fsf-src/work102/gcc/tree-vrp.cc:1084 0x11347063 execute /home/meissner/fsf-src/work102/gcc/tree-vrp.cc:1165 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See for instructions. make[1]: *** [/home/meissner/fsf-src/work102/libgcc/shared-object.mk:14: _mulkc3.o] Error 1 make[1]: Leaving directory '/home/meissner/fsf-build-ppc64le/work102/powerpc64le-unknown-linux-gnu/libgcc' make: *** [Makefile:20623: all-target-libgcc] Error 2 > > I have a patch for making libgcc use the 'right' type that I haven't submitted > > yet. This is because the more general fix that these 3 patches do impacts other > > functions (due to __float128 and _Float128 being different in the current > > compiler when -mabi=ieeelongdouble). > > The patch is to use _Float128 and _Complex _Float128 in libgcc.h instead of trying to use attribute((mode(TF))) and attribute((mode(TC))) in libgcc. Now, this patch fixes the specific problem of not being able to build libgcc (along with patch #1 of the series). But other things show the differences from time time because we are using different internal types and the middle end doesn't know that these types are really the same bits. It is better long term (IMHO) if we have the two types (__float128 and _Float128) use the same internal type (which is what is done in patches #2 and #3). This fixes the other issues that show up, such as creating signaling NaNs for one internal type, and converting it to the other internal type, loses that the NaN is signalling. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com