From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 31C073858CDA for ; Mon, 10 Jul 2023 20:11:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 31C073858CDA 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 36AKALLv025561; Mon, 10 Jul 2023 15:10:21 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 36AKALvi025560; Mon, 10 Jul 2023 15:10:21 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 10 Jul 2023 15:10:21 -0500 From: Segher Boessenkool To: Michael Meissner , gcc-patches@gcc.gnu.org, "Kewen.Lin" , David Edelsohn , Peter Bergner Subject: Re: [PATCH] Fix typo in insn name. Message-ID: <20230710201021.GX19790@gate.crashing.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 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 List-Id: Hi! On Mon, Jul 10, 2023 at 03:59:44PM -0400, Michael Meissner wrote: > In doing other work, I noticed that there was an insn: > > vsx_extract_v4sf__load > > Which did not have an iterator. I removed the useless . This patch does that, you mean. > --- a/gcc/config/rs6000/vsx.md > +++ b/gcc/config/rs6000/vsx.md > @@ -3576,7 +3576,7 @@ (define_insn_and_split "vsx_extract_v4sf" > [(set_attr "length" "8") > (set_attr "type" "fp")]) > > -(define_insn_and_split "*vsx_extract_v4sf__load" > +(define_insn_and_split "*vsx_extract_v4sf_load" > [(set (match_operand:SF 0 "register_operand" "=f,v,v,?r") > (vec_select:SF > (match_operand:V4SF 1 "memory_operand" "m,Z,m,m") Does this fix any ICEs? Or do you have some example that makes better machine code after this change? Or would a better change perhaps be to just remove this pattern completely, if it doesn't do anything useful? I.e., please include a new testcase. Segher