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 145183858C54 for ; Wed, 13 Jul 2022 21:15:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 145183858C54 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26DKgB5p001095; Wed, 13 Jul 2022 21:15:27 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ha5am8uw9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Jul 2022 21:15:26 +0000 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 26DKqZ6G018191; Wed, 13 Jul 2022 21:15:26 GMT Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ha5am8uvt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Jul 2022 21:15:26 +0000 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 26DL5op5002895; Wed, 13 Jul 2022 21:15:25 GMT Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by ppma04wdc.us.ibm.com with ESMTP id 3h71a9pgwq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Jul 2022 21:15:25 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 26DLFOp653018962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Jul 2022 21:15:24 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BCB6A112069; Wed, 13 Jul 2022 21:15:24 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D7C0111207E; Wed, 13 Jul 2022 21:14:11 +0000 (GMT) Received: from lexx (unknown [9.160.8.243]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 13 Jul 2022 21:14:11 +0000 (GMT) Message-ID: <683bc5104bb58cf5e28e3ae8b3560a1ba9bf6cd1.camel@vnet.ibm.com> Subject: Re: [PATCH, rs6000] Cleanup some vstrir define_expand naming inconsistencies From: will schmidt To: Segher Boessenkool Cc: GCC Patches , "Kewen.Lin" , David Edelsohn Date: Wed, 13 Jul 2022 16:14:11 -0500 In-Reply-To: <20220713193907.GU25951@gate.crashing.org> References: <6da1e35def9d282bcf87483e78cf578fff604723.camel@vnet.ibm.com> <20220713193907.GU25951@gate.crashing.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: EtU7bjyrxMemMjrK-H4cxsJqOJUACjM_ X-Proofpoint-ORIG-GUID: QmgvvMfXONiHGS8zhywtHE9gGJrV2iox 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-13_11,2022-07-13_03,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 impostorscore=0 malwarescore=0 bulkscore=0 adultscore=0 spamscore=0 mlxlogscore=724 priorityscore=1501 phishscore=0 suspectscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207130087 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Wed, 13 Jul 2022 21:15:29 -0000 On Wed, 2022-07-13 at 14:39 -0500, Segher Boessenkool wrote: > Hi! > > On Wed, Jul 13, 2022 at 01:18:29PM -0500, will schmidt wrote: > > This cleans up some of the naming around the vstrir and vstril > > instruction definitions, with some cosmetic changes for > > consistency. > > gcc/ > > * config/rs6000/altivec.md (vstrir_code_): Rename > > to vstrir_internal_. > > (vstrir_p_code_): Rename to vstrir_p_internal_. > > (vstril_code_): Rename to vstril_internal_. > > (vstril_p_code_): Rename to vstril_p_internal_. > > It doesn't show the new names on the lhs this way. One way to do > better > is to write e.g. > (vstril_code_): Rename to... > (vstril_internal_): ... this. Ok. > > It often is a good idea to say "... for VIshort" and similar > btw. Ok. > > I'm not a fan of "internal" either, it doesn't say anything. At > least > put it at the very end of the names please? I'm easily convinced. ;-) I wonder if I should just drop "_internal" entirely and go with "vstrir_". Otherwise I'll rework to be "vstrir__internal". At a glance I see we do have some other existing define_insn entries with _internal at the tail and a few others embedded in the middle. I'll leave a note and perhaps review those after. :-) Thanks, -Will > > Okay for trunk with that changed. Thanks! > > > Segher