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 8131B3858D37; Mon, 19 Dec 2022 14:11:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8131B3858D37 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 (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BJDfSck001979; Mon, 19 Dec 2022 14:11:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : references : date : in-reply-to : message-id : content-type : mime-version; s=pp1; bh=n1VKDp0RgAzQwY6CQwpwfdFagbS0JeBhofS0xxh2M9Q=; b=CTk6EnIb/7DsVrayetkoyx8SKuX5NO7woF1fxQ/O1pv+3hbnBaY6hkcuEbsc89tdOT7u 8/jma5RttTGedWzKmS4M9cvruYV9uwFAuSOWxBmCWKiKCq3Abo2pPhd+NIAWmjRJA7CN lNB7Lnofg7ktRZMmg+/euaNal7qHSsPSp1lsdflPFZWGGf2CzQXIwjEgStNXVaHnDIqP +WY6ebozPy9C8fC5H+ra2ve5U5OD0L/GS+5qDFViD5H7Eueqakdh7BshZ2HwELu1XTRH GG5mNNQa4NTyWE63vZ6NaxEtYBCy9zWWKJqouXIHixsb8J4U9aQEkCzhFAg2HPkfUuny vw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mjs2h963g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2022 14:11:24 +0000 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BJE5mWd012618; Mon, 19 Dec 2022 14:11:02 GMT Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mjs2h94sp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2022 14:11:02 +0000 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 2BJCKUDQ022055; Mon, 19 Dec 2022 14:10:09 GMT Received: from smtprelay04.wdc07v.mail.ibm.com ([9.208.129.114]) by ppma03wdc.us.ibm.com (PPS) with ESMTPS id 3mh6yxdskt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2022 14:10:08 +0000 Received: from smtpav06.wdc07v.mail.ibm.com (smtpav06.wdc07v.mail.ibm.com [10.39.53.233]) by smtprelay04.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2BJEA7NL31457702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Dec 2022 14:10:08 GMT Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D8A8658055; Mon, 19 Dec 2022 14:10:06 +0000 (GMT) Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 747445804E; Mon, 19 Dec 2022 14:10:06 +0000 (GMT) Received: from pike (unknown [9.5.12.127]) by smtpav06.wdc07v.mail.ibm.com (Postfix) with ESMTPS; Mon, 19 Dec 2022 14:10:06 +0000 (GMT) From: Jiufu Guo To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, linkw@gcc.gnu.org Subject: Re: [PATCH V6] rs6000: Optimize cmp on rotated 16bits constant References: <20220829034216.94029-1-guojiufu@linux.ibm.com> <20221213210232.GM25951@gate.crashing.org> <7e8rjajsq9.fsf@pike.rch.stglabs.ibm.com> <20221216203635.GF25951@gate.crashing.org> Date: Mon, 19 Dec 2022 22:10:04 +0800 In-Reply-To: <20221216203635.GF25951@gate.crashing.org> (Segher Boessenkool's message of "Fri, 16 Dec 2022 14:36:35 -0600") Message-ID: <7e1qoviiwz.fsf@pike.rch.stglabs.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: KdRkl7GZdOMTVm0T_ueNhvHt8cxS6n49 X-Proofpoint-GUID: jCbJ0sv1fhr14aQ4u5AznqtZMpyk0ilv X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-19_01,2022-12-15_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxscore=0 suspectscore=0 phishscore=0 adultscore=0 mlxlogscore=999 spamscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 bulkscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2212190125 X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_SHORT,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, Segher Boessenkool writes: > On Wed, Dec 14, 2022 at 04:26:54PM +0800, Jiufu Guo wrote: >> Segher Boessenkool writes: >> > On Mon, Aug 29, 2022 at 11:42:16AM +0800, Jiufu Guo wrote: >> >> li %r9,-1 >> >> rldicr %r9,%r9,0,0 >> >> cmpd %cr0,%r3,%r9 >> > >> > FWIW, I find the winnt assembler syntax very hard to read, and I doubt >> > I am the only one. >> Oh, sorry about that. I will avoid to add '-mregnames' to dump asm. :) >> BTW, what options are you used to dump asm code? > > The same as GCC outputs, and as I write assembler code as: bare numbers. > It is much easier to type, and very much easier to read. > > -mregnames is fine for output (and it is the default as well), but > problematic for input. Take for example > li r10,r10 > which translates to > li 10,10 > while what was probably wanted is to load the address of the global > symbol r10, which can be written as > li r10,(r10) > > I do understand that liking the bare numbers syntax is an acquired taste > of course. But less clutter is very useful. This goes hand in hand > with writing multiple asm statements per line, which allows you to group > things together nicely: > li 9,-1 ; rldicr 9,9,0,0 ; cmpd 3,9 > Great! Thanks for your helpful comments! >> > Maybe it is better to not return magic values anyway? So perhaps >> > >> > bool >> > can_be_done_as_compare_of_rotate (unsigned HOST_WIDE_INT c, int clz, int *rot) >> > >> > (with *rot written if the return value is true). >> Thanks for your suggestion! >> It is checking if a constant can be rotated from/to a value which has >> only few tailing nonzero bits (all leading bits are zeros). >> >> So, I'm thinking to name the function as something like: >> can_be_rotated_to_lowbits. > > That is a good name yeah. > >> >> +bool >> >> +compare_rotate_immediate_p (unsigned HOST_WIDE_INT c) >> > >> > No _p please, this function is not a predicate (at least, the name does >> > not say what it tests). So a better name please. This matters even >> > more for extern functions (like this one) because the function >> > implementation is always farther away so you do not easily have all >> > interface details in mind. Good names help :-) >> Thanks! Name is always a matter. :) >> >> Maybe we can name this funciton as "can_be_rotated_as_compare_operand", >> or "is_constant_rotateable_for_compare", because this function checks >> "if a constant can be rotated to/from an immediate operand of >> cmpdi/cmpldi". > > Maybe just "constant_can_be_rotated_to_lowbits"? (If that is what the > function does). It doesn't clearly say that it allows negative numbers > as well, but that is a problem of the function itself already; maybe it > would be better to do signed and unsigned separately. It makes sense. I updated a new version patch. > >> >> +(define_code_iterator eqne [eq ne]) >> >> +(define_code_attr EQNE [(eq "EQ") (ne "NE")]) >> > >> > Just or should work? >> Great! Thanks for point out this! works. >> > >> > Please fix these things. Almost there :-) >> >> I updated the patch as below. Bootstraping and regtesting is ongoing. >> Thanks again for your careful and insight review! > > Please send as new message (not as reply even), that is much easier to > handle. Thanks! Sure, I just submit a new patch version. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608765.html Thanks a lot for your review. BR, Jeff (Jiufu) > > > Segher