From patchwork Mon Dec 4 09:49:17 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kewen.Lin" X-Patchwork-Id: 81265 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B5BD7385C6E9 for ; Mon, 4 Dec 2023 09:49:49 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id CB0823858C5E for ; Mon, 4 Dec 2023 09:49:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CB0823858C5E 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CB0823858C5E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701683372; cv=none; b=xM2hAGpUFrrHVTrTTafoC+5YDQXo9NYGnTEfTqUi8DDB6R2Iz9xoh8ZkGjf3xIma4xZu45JjTuGNuKHweZGbsWlclHV5z9gOYCal1CBr7Ux49UTG2z8awL7IchVMkXu4nIymTE8KR2YivOTa8szJhWmdm0YfGGL3QMPdPKrKjpA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701683372; c=relaxed/simple; bh=ePxTEV1alxxODHfGFf8lgt2vEiq6UgZ8x8amw4R05Ik=; h=DKIM-Signature:Message-ID:Date:To:From:Subject:MIME-Version; b=VsgTQoQlrKZuBkz+UkuIDXQP5gpz1ycsifCNB8jXNzXrgw+56UHAMrW+kiOeWpkMi1cJoH0uleza/k6hfYmdPCE75l5as6tIYt5BJE/L1ypyjuOEzkGafNhI6ZWAgyS5a1aEx/70abzPoMFj0ZTud5ivY4Xl5LQ5sVEoMdERXqY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353728.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3B48C2hu013666; Mon, 4 Dec 2023 09:49:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : to : cc : from : subject : content-type : content-transfer-encoding : mime-version; s=pp1; bh=s9hHEkSANGAMEyhBb9hTKOamRcU1BJkOe3RGiY/GYYk=; b=GGM8DkzU2DBKCGKHM0cOCSvvhrht0YuEvRV8r8/hmBhDzOfIL4nFxaIL/aTY4rW7UXzU EfJyHJmi9nyOP3I3DlTscR+z3dxbM7kRXEZR+x9q3YIftY/P0rHhXHwEsAt8Lk09DoZ+ fmN7YlWdYxZ2XlN/aDYdxIAynmmaR7sQW2w7n6CKdFR2hwQowZZ6wlh4JQT04MvnxhSC 5cWefuVafxcsQTAvOwXElPIu9grdu2fARsF3CYYUlVtE8bDEi7SUnw1V8ObpkpTZ5bwN 1mSEPKcyLIizRdlHBaqj3PV9HJX4i4ppuPqLF3ODnCITELaSFOfviW9EARsUi68nEm9C Qw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3usb20u1jh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Dec 2023 09:49:27 +0000 Received: from m0353728.ppops.net (m0353728.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3B48t8dI016146; Mon, 4 Dec 2023 09:49:26 GMT Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3usb20u1hc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Dec 2023 09:49:26 +0000 Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3B474TY4022502; Mon, 4 Dec 2023 09:49:25 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3urhm1xsbr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Dec 2023 09:49:25 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3B49nMgB10879720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 4 Dec 2023 09:49:23 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D8B3C2004B; Mon, 4 Dec 2023 09:49:22 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F04A520040; Mon, 4 Dec 2023 09:49:18 +0000 (GMT) Received: from [9.177.13.229] (unknown [9.177.13.229]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 4 Dec 2023 09:49:18 +0000 (GMT) Message-ID: Date: Mon, 4 Dec 2023 17:49:17 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: GCC Patches Cc: Andrew MacLeod , "hernandez, aldy" , Michael Meissner , Segher Boessenkool , Peter Bergner , Richard Biener , Jakub Jelinek , Richard Sandiford , David Edelsohn From: "Kewen.Lin" Subject: [PATCH] range: Workaround different type precision issue between _Float128 and long double [PR112788] X-TM-AS-GCONF: 00 X-Proofpoint-GUID: hX0AHi41ERSiYqEjfhqDaqfgEXcFqfU4 X-Proofpoint-ORIG-GUID: kYMQz7eAtH_GHrsgp53vns73RXxI3a66 X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-04_06,2023-11-30_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 bulkscore=0 impostorscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 phishscore=0 malwarescore=0 spamscore=0 lowpriorityscore=0 clxscore=1015 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2312040074 X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Hi, As PR112788 shows, on rs6000 with -mabi=ieeelongdouble type _Float128 has the different type precision (128) from that (127) of type long double, but actually they has the same underlying mode, so they have the same precision as the mode indicates the same real type format ieee_quad_format. It's not sensible to have such two types which have the same mode but different type precisions, some fix attempt was posted at [1]. As the discussion there, there are some historical reasons and practical issues. Considering we passed stage 1 and it also affected the build as reported, this patch is trying to temporarily workaround it. I thought to introduce a hookpod but that seems a bit overkill, assuming scalar float type with the same mode should have the same precision looks sensible. Bootstrapped and regtested on powerpc64-linux-gnu P7/P8/P9 and powerpc64le-linux-gnu P9/P10. Is it ok for trunk? [1] https://inbox.sourceware.org/gcc-patches/718677e7-614d-7977-312d-05a75e1fd5b4@linux.ibm.com/ BR, Kewen ---- PR tree-optimization/112788 gcc/ChangeLog: * value-range.h (range_compatible_p): Workaround same type mode but different type precision issue for rs6000 scalar float types _Float128 and long double. --- gcc/value-range.h | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) -- 2.42.0 diff --git a/gcc/value-range.h b/gcc/value-range.h index 33f204a7171..d0a84754a10 100644 --- a/gcc/value-range.h +++ b/gcc/value-range.h @@ -1558,7 +1558,13 @@ range_compatible_p (tree type1, tree type2) // types_compatible_p requires conversion in both directions to be useless. // GIMPLE only requires a cast one way in order to be compatible. // Ranges really only need the sign and precision to be the same. - return (TYPE_PRECISION (type1) == TYPE_PRECISION (type2) - && TYPE_SIGN (type1) == TYPE_SIGN (type2)); + return TYPE_SIGN (type1) == TYPE_SIGN (type2) + && (TYPE_PRECISION (type1) == TYPE_PRECISION (type2) + // FIXME: As PR112788 shows, for now on rs6000 _Float128 has + // type precision 128 while long double has type precision 127 + // but both have the same mode so their precision is actually + // the same, workaround it temporarily. + || (SCALAR_FLOAT_TYPE_P (type1) + && TYPE_MODE (type1) == TYPE_MODE (type2))); } #endif // GCC_VALUE_RANGE_H