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 92B113858D39 for ; Thu, 21 Oct 2021 06:26:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 92B113858D39 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19L5lWO5009866; Thu, 21 Oct 2021 02:26:01 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3bu2cc0pqn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Oct 2021 02:26:00 -0400 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 19L6Gs7T010000; Thu, 21 Oct 2021 02:26:00 -0400 Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com with ESMTP id 3bu2cc0pq1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Oct 2021 02:26:00 -0400 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 19L6CINg029878; Thu, 21 Oct 2021 06:25:57 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma04ams.nl.ibm.com with ESMTP id 3bqpcb366q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Oct 2021 06:25:57 +0000 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 19L6PtBP55509396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Oct 2021 06:25:55 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3D1A04C044; Thu, 21 Oct 2021 06:25:55 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 62D6B4C04A; Thu, 21 Oct 2021 06:25:53 +0000 (GMT) Received: from [9.200.55.126] (unknown [9.200.55.126]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 21 Oct 2021 06:25:53 +0000 (GMT) Message-ID: Date: Thu, 21 Oct 2021 14:25:51 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [PATCH, rs6000] Disable gimple fold for float or double vec_minmax when fast-math is not set Content-Language: en-US To: Segher Boessenkool Cc: gcc-patches , David , Bill Schmidt References: <787f0d5d-a8f5-c513-997f-a5b906951da4@linux.ibm.com> <20211020161900.GS614@gate.crashing.org> From: HAO CHEN GUI In-Reply-To: <20211020161900.GS614@gate.crashing.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: NdlNmAbLrHrKQwL_VAzvknmhJu5nMN_i X-Proofpoint-GUID: ip5juxIblPhw3BsvFq32189wCgl-RROM X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-21_01,2021-10-20_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxlogscore=999 priorityscore=1501 malwarescore=0 bulkscore=0 impostorscore=0 phishscore=0 adultscore=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110210027 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, BODY_8BITS, 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 06:26:05 -0000 On 21/10/2021 上午 12:19, Segher Boessenkool wrote: > Hi! > > On Wed, Oct 20, 2021 at 05:04:56PM +0800, HAO CHEN GUI wrote: >> This patch disables gimple folding for float or double vec_min/max when fast-math is not set. It makes vec_min/max conform with the guide. >> >> Bootstrapped and tested on powerpc64le-linux with no regressions. Is this okay for trunk? Any recommendations? Thanks a lot. >> >>   I refined the patch according to reviewers' advice. The attachments are >> the ChangeLog and patch diff in case the email body is messed up. >> >> >> ChangeLog >> >> 2021-10-20 Haochen Gui >> >> gcc/ >>         * config/rs6000/rs6000-call.c (rs6000_gimple_fold_builtin): >>         Disable gimple fold for VSX_BUILTIN_XVMINDP, >> ALTIVEC_BUILTIN_VMINFP, >>         VSX_BUILTIN_XVMAXDP, ALTIVEC_BUILTIN_VMAXFP when fast-math >> is not >>         set. > Content-Type: text/plain; charset=UTF-8; format=flowed > > Please don't use flowed. It makes patches unreadable and unusable if > you do (they will not apply anymore). > > Also, the left border should be one tab, not eight spaces, and the right > border is at 80 chars (so there are 72 usable chars on a line). Don't > end a line in ":" if you don't overflow a line if you put text after it. I found the settings of the format in my client configuration. Thanks for reminder. >> --- a/gcc/config/rs6000/rs6000-call.c >> +++ b/gcc/config/rs6000/rs6000-call.c >> @@ -12159,6 +12159,14 @@ rs6000_gimple_fold_builtin (gimple_stmt_iterator >> *gsi) >>        return true; >>      /* flavors of vec_min.  */ >>      case VSX_BUILTIN_XVMINDP: >> +    case ALTIVEC_BUILTIN_VMINFP: >> +      { >> +       lhs = gimple_call_lhs (stmt); >> +       tree type = TREE_TYPE (lhs); >> +       if (HONOR_NANS (type) || HONOR_SIGNED_ZEROS (type)) >> +         return false; >> +       gcc_fallthrough (); >> +      } > Both vminfp anf xvmindp (and xvminsp and xsmindp) return -0 or the > minimum of +0 and -0, that is okay even with HONOR_SIGNED_ZEROS, I > think? Yes, the HONOR_SIGNED_ZEROS is unnecessary. > x[sv]min[sd]p returns the number for the minimum of a NaN and a number, > but vminfp returns a NaN. Do you really want to make the xvmindp > builtin handle less than it does currently? And, what about vminfp? > Did tht do the wrong thing before? x[sv]min[sd]p meets the requirement of IEEE std 754-2008 while xsmincdp doesn't. This patch prevents the builtin to be converted to xsmincdp.  If the two elements in the vectors are the same, the vector comparison is optimized to scalar comparison. MAX_EXPR at vector low pass, MAX_EXPR On P9, the scalar comparison is implemented by xs[min|max]cdp.It doesn't conform with IEEE std 754-2008. The puzzle here is that both x[sv]min[sd]p and xs[min|max]cdp doesn't conform the latest IEEE standard 754-2019 which says "return a quiet NaN if either operand is a NaN". The builtin would never be implemented by vminfp, I think. Gui Haochen > > There are no tests for any of that apparently. Hrm. > > > Segher