From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id C27FD385C40F for ; Mon, 18 Jul 2022 08:51:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C27FD385C40F Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26I8Z8F9004736; Mon, 18 Jul 2022 08:51:44 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hd44x8efp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2022 08:51:44 +0000 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 26I8ZxGI007358; Mon, 18 Jul 2022 08:51:43 GMT Received: from ppma04fra.de.ibm.com (6a.4a.5195.ip4.static.sl-reverse.com [149.81.74.106]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hd44x8ef5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2022 08:51:43 +0000 Received: from pps.filterd (ppma04fra.de.ibm.com [127.0.0.1]) by ppma04fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 26I8KxBM029718; Mon, 18 Jul 2022 08:33:25 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma04fra.de.ibm.com with ESMTP id 3hbmy8hrfn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2022 08:33:24 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 26I8XLZO23920896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 18 Jul 2022 08:33:21 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C84E852054; Mon, 18 Jul 2022 08:33:21 +0000 (GMT) Received: from [9.197.227.236] (unknown [9.197.227.236]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 0E29B52050; Mon, 18 Jul 2022 08:33:19 +0000 (GMT) Message-ID: Date: Mon, 18 Jul 2022 16:33:18 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH v3, rs6000] Disable TImode from Bool expanders [PR100694, PR93123] Content-Language: en-US To: Segher Boessenkool Cc: gcc-patches , David , "Kewen.Lin" , Peter Bergner References: <001654df-a083-c10f-6c0f-dfda0de6e87b@linux.ibm.com> <20220712172606.GP25951@gate.crashing.org> From: HAO CHEN GUI In-Reply-To: <20220712172606.GP25951@gate.crashing.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: Ce1xRYe-31SoV6RfYsGR6EGICh5nj70j X-Proofpoint-ORIG-GUID: O1WwWo-z_CwHAB5QTuTFwMLvEIU2uqLT X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-07-18_08,2022-07-15_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 bulkscore=0 impostorscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 spamscore=0 suspectscore=0 malwarescore=0 adultscore=0 clxscore=1015 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207180036 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Mon, 18 Jul 2022 08:51:47 -0000 Hi Segher, Thanks for your comments. On 13/7/2022 上午 1:26, Segher Boessenkool wrote: >> --- a/gcc/config/rs6000/rs6000.md >> +++ b/gcc/config/rs6000/rs6000.md >> @@ -7078,27 +7078,38 @@ (define_expand "subti3" >> }) >> >> ;; 128-bit logical operations expanders >> +;; Fail TImode in all 128-bit logical operations expanders and split it into >> +;; two DI registers. >> >> (define_expand "and3" >> [(set (match_operand:BOOL_128 0 "vlogical_operand") >> (and:BOOL_128 (match_operand:BOOL_128 1 "vlogical_operand") >> (match_operand:BOOL_128 2 "vlogical_operand")))] >> "" >> - "") >> +{ >> + if (mode == TImode) >> + FAIL; >> +}) > It is better to not FAIL it, but simply not have a pattern for the > TImode version at all. > > Does nothing depend on the :TI version to exist? > > What about the :PTI version? Getting rid of that as well will allow > some nice optimisations. > > Of course we *do* have instructions to do such TImode ops, on newer > CPUs, but in vector registers only. It isn't obvious what is faster. > During expand, TI mode is split to two registers when it can't match any expands. So I failed TI mode in each expand and expect to be split at expand. TI mode is still in some insn_and_split patterns (e.g. "*and3_internal"). If later rtl passes generate TI mode logical operations, they still can be matched. Originally, the TI mode is split after reload pass by rs6000_split_logical. It's too late to catch some rtl optimizations. For the PTI, it can't be split to two registers during expand. PTI requires an even/odd register pair. So splitting it after reload can make sure it gets correct registers, I think. >From my understanding, it's sub-optimal to use vector logical operation instructions for TI mode if the destination is an integer operand. It needs three instructions (move to vector register, vector logical operation and move from vector register). When splitting TImode, it only needs two logical instructions on two separate registers. Thanks again Gui Haochen