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 E5FAF3858D28; Wed, 12 Apr 2023 12:48:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E5FAF3858D28 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 (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33CBtaQ7032043; Wed, 12 Apr 2023 12:48:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=lTKE8nzoCCP3exrowJpHWsvEyXXRohs3BYKmxfwirdo=; b=bIlKX7vr8mNdcKH8I19ENwe8PRlEh2u/BEGKDueZcJZjZc7uyGyOmI+6ZUVpOHt/bsBv RZzUZXq1CHsn/8zxDxMgcLm1ZuH8G/1b/l7cMEUsb2u9qSFsOWo232GjvDMfoj7GlOsS BjZzheDtgrbQcBxY3wSJcgGspbwRCnslXklQRdH8hLgxEEkQkYnanLtsJIjHU6w2xLcf L+csk933XNW1adEjVsr5EHWbGNYdu4p5AG/iQvYY0vzmRPBa4FIqRx3zPNMfWkRoyW4F BmFuOVN0V+i1lUtJn7xdRg2R0aLeyyi/mJqC/Zd/RM24T3OBZKkAKXTTIzkfzS5deljw ww== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3pwv6wt3wv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2023 12:48:09 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 33CBvBVI007215; Wed, 12 Apr 2023 12:48:09 GMT Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3pwv6wt3uq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2023 12:48:08 +0000 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 33C4nYHt026789; Wed, 12 Apr 2023 12:48:06 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma04ams.nl.ibm.com (PPS) with ESMTPS id 3pu0m1achb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2023 12:48:06 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 33CCm3pP24969982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 12 Apr 2023 12:48:03 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E8C9D20043; Wed, 12 Apr 2023 12:48:02 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6391320040; Wed, 12 Apr 2023 12:48:00 +0000 (GMT) Received: from [9.177.7.12] (unknown [9.177.7.12]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 12 Apr 2023 12:48:00 +0000 (GMT) Message-ID: <7efe959e-2ceb-1aa3-6f83-ecf9ffa35a6f@linux.ibm.com> Date: Wed, 12 Apr 2023 20:47:58 +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] testsuite: update requires for powerpc/float128-cmp2-runnable.c Content-Language: en-US To: Segher Boessenkool , guojiufu Cc: dje.gcc@gmail.com, linkw@gcc.gnu.org, meissner@linux.ibm.com, gcc-patches@gcc.gnu.org References: <20230410020941.2440885-1-guojiufu@linux.ibm.com> <11b29ca1-cd23-1a48-4ad8-3b472d38fd2f@linux.ibm.com> <71ed6f665ae2ed9678d8dc4ec0f620ce@linux.ibm.com> <13ec00da-587b-847d-c26b-98cf463f21ac@linux.ibm.com> <20230411151335.GB19790@gate.crashing.org> From: "Kewen.Lin" In-Reply-To: <20230411151335.GB19790@gate.crashing.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: jLhGnOG7HmgC7r88UHcn84cqUcTKVCLW X-Proofpoint-ORIG-GUID: gDIHiMgVkxpHyB2mp0RPgWXSGEGOsYU7 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-12_04,2023-04-12_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxscore=0 impostorscore=0 malwarescore=0 adultscore=0 priorityscore=1501 spamscore=0 suspectscore=0 mlxlogscore=999 clxscore=1015 lowpriorityscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304120112 X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,NICE_REPLY_A,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 Segher & Jeff, on 2023/4/11 23:13, Segher Boessenkool wrote: > On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote: >> on 2023/4/11 17:14, guojiufu wrote: >>> Thanks for raising this concern. >>> The behavior to check about bif on FLOAT128_HW and emit an error message for >>> requirements on quad-precision is added in gcc12. This is why gcc12 fails to >>> compile the case on -m32. >>> >>> Before gcc12, altivec_resolve_overloaded_builtin will return the overloaded >>> result directly, and does not check more about the result function. >> >> Thanks for checking, I wonder which commit caused this behavior change and what's >> the underlying justification? I know there is one new bif handling framework Answered this question by myself with some diggings, test case float128-cmp2-runnable.c started to fail from r12-5752-gd08236359eb229 which exactly makes new bif framework start to take effect and the reason why the behavior changes is the condition change from **TARGET_P9_VECTOR** to **TARGET_FLOAT128_HW**. With r12-5751-gc9dd01314d8467 (still old bif framework): $ grep -r scalar_cmp_exp_qp gcc/config/rs6000/rs6000-builtin.def BU_P9V_VSX_2 (VSCEQPGT, "scalar_cmp_exp_qp_gt", CONST, xscmpexpqp_gt_kf) BU_P9V_VSX_2 (VSCEQPLT, "scalar_cmp_exp_qp_lt", CONST, xscmpexpqp_lt_kf) BU_P9V_VSX_2 (VSCEQPEQ, "scalar_cmp_exp_qp_eq", CONST, xscmpexpqp_eq_kf) BU_P9V_VSX_2 (VSCEQPUO, "scalar_cmp_exp_qp_unordered", CONST, xscmpexpqp_unordered_kf) BU_P9V_OVERLOAD_2 (VSCEQPGT, "scalar_cmp_exp_qp_gt") BU_P9V_OVERLOAD_2 (VSCEQPLT, "scalar_cmp_exp_qp_lt") BU_P9V_OVERLOAD_2 (VSCEQPEQ, "scalar_cmp_exp_qp_eq") BU_P9V_OVERLOAD_2 (VSCEQPUO, "scalar_cmp_exp_qp_unordered") There were only 13 bifs requiring TARGET_FLOAT128_HW in old bif framework. $ grep ^BU_FLOAT128_HW gcc/config/rs6000/rs6000-builtin.def BU_FLOAT128_HW_VSX_1 (VSEEQP, "scalar_extract_expq", CONST, xsxexpqp_kf) BU_FLOAT128_HW_VSX_1 (VSESQP, "scalar_extract_sigq", CONST, xsxsigqp_kf) BU_FLOAT128_HW_VSX_1 (VSTDCNQP, "scalar_test_neg_qp", CONST, xststdcnegqp_kf) BU_FLOAT128_HW_VSX_2 (VSIEQP, "scalar_insert_exp_q", CONST, xsiexpqp_kf) BU_FLOAT128_HW_VSX_2 (VSIEQPF, "scalar_insert_exp_qp", CONST, xsiexpqpf_kf) BU_FLOAT128_HW_VSX_2 (VSTDCQP, "scalar_test_data_class_qp", CONST, xststdcqp_kf) BU_FLOAT128_HW_1 (SQRTF128_ODD, "sqrtf128_round_to_odd", FP, sqrtkf2_odd) BU_FLOAT128_HW_1 (TRUNCF128_ODD, "truncf128_round_to_odd", FP, trunckfdf2_odd) BU_FLOAT128_HW_2 (ADDF128_ODD, "addf128_round_to_odd", FP, addkf3_odd) BU_FLOAT128_HW_2 (SUBF128_ODD, "subf128_round_to_odd", FP, subkf3_odd) BU_FLOAT128_HW_2 (MULF128_ODD, "mulf128_round_to_odd", FP, mulkf3_odd) BU_FLOAT128_HW_2 (DIVF128_ODD, "divf128_round_to_odd", FP, divkf3_odd) BU_FLOAT128_HW_3 (FMAF128_ODD, "fmaf128_round_to_odd", FP, fmakf4_odd) Starting from r12-5752-gd08236359eb229, these scalar_cmp_exp_qp_{gt,lt,eq,unordered} bifs were put under stanza ieee128-hw, it makes ieee128-hw to have 17 bifs, comparing to the previous, the extra four ones were exactly these scalar_cmp_exp_qp_{gt,lt,eq,unordered}. >> introduced in gcc12, not sure the checking condition was changed together or by >> a standalone commit. Anyway, apparently the conditions for the support of these >> bifs are different on gcc-11 and gcc-12, I wonder why it changed. As mentioned >> above, PR108758's c#1 said this case (bifs) work well on gcc-11, I suspected the >> condition change was an overkill, that's why I asked. > > It almost certainly was an oversight. The new builtin framework changed > so many things, there was bound to be some breakage to go with all the > good things it brought. Yeah, as the above findings, also I found that r12-3126-g2ed356a4c9af06 introduced power9 related stanzas and r12-3167-g2f9489a1009d98 introduced ieee128-hw stanza including these four bifs, both of them don't have any notes on why we would change the condition for these scalar_cmp_exp_qp_{gt,lt,eq,unordered} from power9-vector to ieee128-hw, so I think it's just an oversight (ieee128-hw is an overkill comparing to power9-vector :)). > > So what is the actual thing going wrong? QP insns work fine and are > valid on all systems and environments, BE or LE, 32-bit or 64-bit. Of > course you cannot use the "long double" type for those everywhere, but > that is a very different thing. The actual thing going wrong is that: the test case float128-cmp2-runnable.c runs well on BE -m32 and -m64 with gcc-11, but meets failures on BE -m32 with latest gcc-12 and trunk during compilation, having the error messages like: gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c: In function 'main': gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:155:3: error: '__builtin_vsx_scalar_cmp_exp_qp_eq' requires ISA 3.0 IEEE 128-bit floating point As scalar_cmp_exp_qp_{gt,lt,eq,unordered} requires condition TARGET_FLOAT128_HW now (since new bif framework took effect). (To be more exact, it started to fail from r12-5752-gd08236359eb229). IMHO, the apparent cause seems to be the wrong effective target mismatching the condition for those bifs, but the underlying cause is that new bif framework unexpectedly moved these four bifs from power9-vector to ieee128-hw. Testing a diff as below: diff --git a/gcc/config/rs6000/rs6000-builtins.def b/gcc/config/rs6000/rs6000-builtins.def index 03fb194b151..67a3f5edaf2 100644 --- a/gcc/config/rs6000/rs6000-builtins.def +++ b/gcc/config/rs6000/rs6000-builtins.def @@ -2797,6 +2797,19 @@ const vsi __builtin_vsx_xxbrw_v4si (vsi); XXBRW_V4SI p9_xxbrw_v4si {} + const signed int __builtin_vsx_scalar_cmp_exp_qp_eq (_Float128, _Float128); + VSCEQPEQ xscmpexpqp_eq_kf {} + + const signed int __builtin_vsx_scalar_cmp_exp_qp_gt (_Float128, _Float128); + VSCEQPGT xscmpexpqp_gt_kf {} + + const signed int __builtin_vsx_scalar_cmp_exp_qp_lt (_Float128, _Float128); + VSCEQPLT xscmpexpqp_lt_kf {} + + const signed int \ + __builtin_vsx_scalar_cmp_exp_qp_unordered (_Float128, _Float128); + VSCEQPUO xscmpexpqp_unordered_kf {} + ; Miscellaneous P9 functions [power9] @@ -2879,19 +2892,6 @@ fpmath _Float128 __builtin_mulf128_round_to_odd (_Float128, _Float128); MULF128_ODD mulkf3_odd {} - const signed int __builtin_vsx_scalar_cmp_exp_qp_eq (_Float128, _Float128); - VSCEQPEQ xscmpexpqp_eq_kf {} - - const signed int __builtin_vsx_scalar_cmp_exp_qp_gt (_Float128, _Float128); - VSCEQPGT xscmpexpqp_gt_kf {} - - const signed int __builtin_vsx_scalar_cmp_exp_qp_lt (_Float128, _Float128); - VSCEQPLT xscmpexpqp_lt_kf {} - - const signed int \ - __builtin_vsx_scalar_cmp_exp_qp_unordered (_Float128, _Float128); - VSCEQPUO xscmpexpqp_unordered_kf {} - fpmath _Float128 __builtin_sqrtf128_round_to_odd (_Float128); SQRTF128_ODD sqrtkf2_odd {} BR, Kewen