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 BD5DF3858D3C for ; Mon, 28 Nov 2022 06:17:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BD5DF3858D3C 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 (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AS65maq016721; Mon, 28 Nov 2022 06:17:07 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=aY2U5yb8eXfXvR0fNJv+UaN1wfB/qLsVtVl26rgYnVE=; b=XWVh8j3MHaO2BnzzcONb0D9sY/nsajMuJdqgoKoTjud0N4vKlqvlcKssRU3/EkQST6l7 vipfhPRt3bB9iBK1ATaGHNT5t80jDYu/SM5A8h7WHvsA8RMWsHbsR0eDSoUaJTmmyjy0 VA+Jcx34YvFeHv/bIaGgsx1VaY8IO8QHq9Pt6VC7mnFyF7AjUyaBwjkPgTeM8eo1fiAM RYU/dNjXEvCpPoNrKMwiG5eL74IsTjrYIOwzS78N9hONSSbKecoNWMVKOQRzctpaorru JAO8wOn9BDn9gVGlJvT/ChjKeXMSOkfMdFxOng2QjV92NnndLYxK6JdPTny+Y3rKqZ8F Eg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m3vmr785d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 06:17:07 +0000 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2AS5tEBM023679; Mon, 28 Nov 2022 06:17:07 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m3vmr784q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 06:17:06 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2AS66F7J031625; Mon, 28 Nov 2022 06:17:04 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma06ams.nl.ibm.com with ESMTP id 3m3a2ht1gm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 06:17:04 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2AS6H0FT2884182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Nov 2022 06:17:00 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 57E7DA405B; Mon, 28 Nov 2022 06:17:00 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BF813A4054; Mon, 28 Nov 2022 06:16:56 +0000 (GMT) Received: from [9.200.36.84] (unknown [9.200.36.84]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 28 Nov 2022 06:16:56 +0000 (GMT) Message-ID: <2c1956bc-8777-cb29-ab1c-8a3517287571@linux.ibm.com> Date: Mon, 28 Nov 2022 14:16:54 +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] Change the behavior of predicate check failure on cbranchcc4 operand0 in prepare_cmp_insn Content-Language: en-US To: HAO CHEN GUI Cc: Segher Boessenkool , David , Peter Bergner , gcc-patches , Richard Sandiford , Richard Biener , Jeff Law , Jakub Jelinek , Michael Meissner References: <4a052a62-7861-ed6f-9801-3b58ac384f81@linux.ibm.com> From: "Kewen.Lin" In-Reply-To: <4a052a62-7861-ed6f-9801-3b58ac384f81@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: P5Bi9gm1xgWmAa2OuVv69VHm9vHReqV_ X-Proofpoint-ORIG-GUID: oe_TH_Tbu4QY_kq5Gv8oRtTCFXmQxSKy X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-28_05,2022-11-25_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 spamscore=0 priorityscore=1501 mlxlogscore=999 impostorscore=0 mlxscore=0 bulkscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211280043 X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,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: Add more experts in CC. on 2022/11/23 10:54, HAO CHEN GUI wrote: > Hi, > I want to enable "have_cbranchcc4" on rs6000. But not all combinations of > comparison codes and sub CC modes are benefited to generate cbranchcc4 insns > on rs6000. There is an predicate for operand0 of cbranchcc4 to bypass > some combinations. It gets assertion failure in prepare_cmp_insn. I think > we shouldn't suppose that all comparison codes and sub CC modes are supported > and throw an assertion failure in prepare_cmp_insn. It might check the > predicate and go to fail if the predicate can't be satisfied. This patch > changes the behavior of those codes. > > Bootstrapped and tested on powerpc64-linux BE/LE and x86 with no regressions. > Is this okay for trunk? Any recommendations? Thanks a lot. > > > ChangeLog > 2022-11-23 Haochen Gui > > gcc/ > * optabs.cc (prepare_cmp_insn): Go to fail other than assert it when > predicate check of "cbranchcc4" operand[0] fails. > > patch.diff > diff --git a/gcc/optabs.cc b/gcc/optabs.cc > index 165f8d1fa22..3ec8f6b17ba 100644 > --- a/gcc/optabs.cc > +++ b/gcc/optabs.cc > @@ -4484,8 +4484,9 @@ prepare_cmp_insn (rtx x, rtx y, enum rtx_code comparison, rtx size, > { > enum insn_code icode = optab_handler (cbranch_optab, CCmode); > test = gen_rtx_fmt_ee (comparison, VOIDmode, x, y); > - gcc_assert (icode != CODE_FOR_nothing > - && insn_operand_matches (icode, 0, test)); > + gcc_assert (icode != CODE_FOR_nothing); > + if (!insn_operand_matches (icode, 0, test)) > + goto fail; IMHO, this change looks to accord with the other code in prepare_cmp_insn, which allows the preparation to fail with NULL_RTX ptest. Its caller can make its own decision (ICE due to unexpected, or try other ways) when ptest is null. If this direction is sensible, maybe we can make it goto fail too if the icode == CODE_FOR_nothing, since we already try to relax the restriction. BR, Kewen > *ptest = test; > return; > }