From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <segher@kernel.crashing.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
 by sourceware.org (Postfix) with ESMTP id 09C793856DCA
 for <gcc-patches@gcc.gnu.org>; Wed, 13 Jul 2022 19:40:09 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 09C793856DCA
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none)
 header.from=kernel.crashing.org
Authentication-Results: sourceware.org;
 spf=pass smtp.mailfrom=kernel.crashing.org
Received: from gate.crashing.org (localhost.localdomain [127.0.0.1])
 by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 26DJd9sH027253;
 Wed, 13 Jul 2022 14:39:09 -0500
Received: (from segher@localhost)
 by gate.crashing.org (8.14.1/8.14.1/Submit) id 26DJd8G2027252;
 Wed, 13 Jul 2022 14:39:08 -0500
X-Authentication-Warning: gate.crashing.org: segher set sender to
 segher@kernel.crashing.org using -f
Date: Wed, 13 Jul 2022 14:39:07 -0500
From: Segher Boessenkool <segher@kernel.crashing.org>
To: will schmidt <will_schmidt@vnet.ibm.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, "Kewen.Lin" <linkw@linux.ibm.com>, 
 David Edelsohn <dje.gcc@gmail.com>
Subject: Re: [PATCH,
 rs6000] Cleanup some vstrir define_expand naming inconsistencies
Message-ID: <20220713193907.GU25951@gate.crashing.org>
References: <6da1e35def9d282bcf87483e78cf578fff604723.camel@vnet.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6da1e35def9d282bcf87483e78cf578fff604723.camel@vnet.ibm.com>
User-Agent: Mutt/1.4.2.3i
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL,
 KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=no 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 <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2022 19:40:11 -0000

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_<mode>): Rename
> 	to vstrir_internal_<mode>.
> 	(vstrir_p_code_<mode>): Rename to vstrir_p_internal_<mode>.
> 	(vstril_code_<mode>): Rename to vstril_internal_<mode>.
> 	(vstril_p_code_<mode>): Rename to vstril_p_internal_<mode>.

It doesn't show the new names on the lhs this way.  One way to do
better
is to write e.g.
	(vstril_code_<mode>): Rename to...
	(vstril_internal_<mode>): ... this.

It often is a good idea to say "...<mode> for VIshort" and similar btw.

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?

Okay for trunk with that changed.  Thanks!


Segher