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 DF0F53854577 for ; Fri, 18 Nov 2022 06:35:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF0F53854577 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 2AI61mRG020556; Fri, 18 Nov 2022 06:35: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=P+LNkiMeY+llb5qp6+bbgAk6EOEkIqeCX1j+67YeyHs=; b=ltcCUuePXpxRwqWxtnFnVstJAFgZTlRFLWgrTI0n1vRGeRYKY5X+hAv0meoZxZr18m0T DaXmsXmTmmjCTeN7IA65gd85wRIXH9HPCnrEvHBPDf2EsbuSTV7sXQS9yU1THgNjSVnQ xuW8BPi86cyJQElB9IRdJ/mDG9Kv0jHfkK2XqRZWc9K8cOzJqD/66qREvRpyXAe5O5Sa yBZOkOThQldbOZamg7IAmQY3A301JZwFtrSPs+iDOcGV2LVm4AQIc4e3Dp/qRcjVyJ76 07hLsQs4MQOTjYU2/ymvwnghSaDldY5V/AAySJpB8nDhHg1jntl0KL9J8EiD72HLjBim wQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3kx4e0rp4a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Nov 2022 06:35:39 +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 2AI6KIAQ008613; Fri, 18 Nov 2022 06:35:39 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 3kx4e0rp3n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Nov 2022 06:35:39 +0000 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 2AI6KRDF020336; Fri, 18 Nov 2022 06:35:36 GMT Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by ppma04ams.nl.ibm.com with ESMTP id 3kwtp50jky-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Nov 2022 06:35:36 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2AI6ZXA264487866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 Nov 2022 06:35:33 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7FBEAA4054; Fri, 18 Nov 2022 06:35:33 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9BA63A405C; Fri, 18 Nov 2022 06:35:31 +0000 (GMT) Received: from [9.200.36.31] (unknown [9.200.36.31]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 18 Nov 2022 06:35:31 +0000 (GMT) Message-ID: Date: Fri, 18 Nov 2022 14:35:30 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCHv2, rs6000] Enable have_cbranchcc4 on rs6000 To: David Edelsohn Cc: gcc-patches , Segher Boessenkool , "Kewen.Lin" , Peter Bergner References: <438c6628-0b9c-e5d0-e198-2fd6edd16a93@linux.ibm.com> From: HAO CHEN GUI In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 6vbwgOjJp80TsaisDy02imFkzVsZuSlo X-Proofpoint-ORIG-GUID: P0Xf_ODDbLhDg8vXNvt-jY1EPd-fCXIx 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-17_06,2022-11-17_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 impostorscore=0 malwarescore=0 suspectscore=0 clxscore=1015 phishscore=0 mlxlogscore=954 spamscore=0 priorityscore=1501 lowpriorityscore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211180044 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_NUMSUBJECT,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 David, 在 2022/11/17 21:24, David Edelsohn 写道: > This is better, but the pattern should be near and after the existing cbranch4 patterns earlier in the file, not the *cbranch pattern.  It doesn't match the comment. Sure, I will put it after existing "cbranch4" patterns. > > Why are you using zero_constant predicate instead of matching (const_int 0) for operand 2? The "const_int 0" is an operand other than a predicate. We need a predicate here. > > Why does this need the new all_branch_comparison_operator?  Can the ifcvt optimization correctly elide the 2 insn sequence? Because rs6000 defines "*cbranch_2insn" insn, such insns are generated after expand. (jump_insn 50 47 51 11 (set (pc) (if_then_else (ge (reg:CCFP 156) (const_int 0 [0])) (label_ref 53) (pc))) "/home/guihaoc/gcc/gcc-mainline-base/gmp/mpz/cmpabs_d.c":80:7 884 {*cbranch_2insn} (expr_list:REG_DEAD (reg:CCFP 156) (int_list:REG_BR_PROB 633507684 (nil))) -> 53) In prepare_cmp_insn, the comparison is verified by insn_operand_matches. If extra_insn_branch_comparison_operator is not included in "cbranchcc4" predicate, it hits ICE here. if (GET_MODE_CLASS (mode) == MODE_CC) { 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)); *ptest = test; return; } The real conditional move is generated by emit_conditional_move_1. Commonly "*cbranch_2insn" can't be optimized out and it returns NULL_RTX. if (COMPARISON_P (comparison)) { saved_pending_stack_adjust save; save_pending_stack_adjust (&save); last = get_last_insn (); do_pending_stack_adjust (); machine_mode cmpmode = comp.mode; prepare_cmp_insn (XEXP (comparison, 0), XEXP (comparison, 1), GET_CODE (comparison), NULL_RTX, unsignedp, OPTAB_WIDEN, &comparison, &cmpmode); if (comparison) { rtx res = emit_conditional_move_1 (target, comparison, op2, op3, mode); if (res != NULL_RTX) return res; } delete_insns_since (last); restore_pending_stack_adjust (&save); I think that extra_insn_branch_comparison_operator should be included in "cbranchcc4" predicates as such insns exist. And leave it to emit_conditional_move which decides whether it can be optimized or not. Thanks for your comments Gui Haochen