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 A01993858D32; Thu, 13 Apr 2023 08:28:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A01993858D32 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 (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33D8EC7R029560; Thu, 13 Apr 2023 08:28:40 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=NUdui76mUr1zXHvfkp1HONsXZymDRwIqgpqOxoFT5vM=; b=r6eOkjCcj97YLOPbNLvsyvSr4YmMHqOpCaSEcbs1Ozi1LGA5yPajIm6tOeBcnLT2Mbf7 JuYIKnbVtp7LTjR8uD9G8flhCfuH8k8dNWsyfpTcFkQ+YG0s227eGbYkM4hOt3ZiB3H5 G6JYGmhVS8iS/Mmq0fUxxLBbKR8GBneJWTt8QSZ9bp0lwo9kJT7b2w+X5Mrvri64vG1R K6LcU0p9JlQdhQ8ccHU42Zfs0CmnYabwt+vpTsbqDSKg+bneAsnjPPLjbvJZ5TPA2HaW krBGyXy6mpPwb79vFmmQioxruMsP8K9QiNtK5YsfezoCmEqU2At5T9jlcSMLfa7aw1Nm SQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3pxe1y0hbv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Apr 2023 08:28:39 +0000 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 33D8EPNw031093; Thu, 13 Apr 2023 08:28:39 GMT Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3pxe1y0hb4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Apr 2023 08:28:39 +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 33C6owmR001566; Thu, 13 Apr 2023 08:28:37 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma04ams.nl.ibm.com (PPS) with ESMTPS id 3pu0m1avg2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Apr 2023 08:28:37 +0000 Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com [10.20.54.103]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 33D8SPUo30016070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Apr 2023 08:28:27 GMT Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5FFD22044D; Thu, 13 Apr 2023 08:09:19 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B16A62043F; Thu, 13 Apr 2023 08:09:15 +0000 (GMT) Received: from [9.177.24.145] (unknown [9.177.24.145]) by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 13 Apr 2023 08:09:15 +0000 (GMT) Message-ID: Date: Thu, 13 Apr 2023 16:09:13 +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: guojiufu Cc: Segher Boessenkool , 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> <7efe959e-2ceb-1aa3-6f83-ecf9ffa35a6f@linux.ibm.com> <1a4b3c8fd186b3a5a07e4fd4d73bc6ff@linux.ibm.com> From: "Kewen.Lin" In-Reply-To: <1a4b3c8fd186b3a5a07e4fd4d73bc6ff@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: pYF--A7x5mGhExfbXm84pmyHIW21dD8- X-Proofpoint-ORIG-GUID: qOCoyDLW55Cd1EEpxL8-a_C8KUMkYX_0 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-13_04,2023-04-12_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 phishscore=0 suspectscore=0 bulkscore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 mlxlogscore=999 priorityscore=1501 adultscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304130073 X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,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 Jeff, on 2023/4/13 15:45, guojiufu wrote: > Hi, > > On 2023-04-12 20:47, Kewen.Lin wrote: >> 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 {} >> > > Thanks a lot for your great findings and comments! > > I understand your points: > 1.  This is `regression`:  float128-cmp2-runnable.c pass and runs well on gcc-11. >     But fail to compile with gcc12 and trunk. > 2.  Trunk(or gcc-12) fail to compile this case because the bifs >     (e.g. __builtin_vsx_scalar_cmp_exp_qp_eq) are put under [ieee128-hw]. >     (This may be an unexpected/unintended change.) > and 3. xscmpexpqp (QP insn) is valid on power9 system (no matter BE/LE, -m32/-64): >     define_insn for xscmpexpqp's condition is "TARGET_P9_VECTOR". > > So, We may fix the regression first. >     "updating those bifs (scalar_cmp_exp_qp) to make them can be compiled on P9/BE/-m32" >     would be a fix for this regression. > Thanks for the summary, yeah, this is a regression IMHO. Those bifs worked well on Power9 BE -m32 in the past, it's not sensible to disable them there. Also considering the corresponding define_insn condition and commit history etc, I believe it's an oversight, and we should fix the sitting stanza instead of the test case. BR, Kewen