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 04C153858C51 for ; Mon, 28 Mar 2022 17:15:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 04C153858C51 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 22SHEAUM020271; Mon, 28 Mar 2022 12:14:10 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 22SHE9Kh020270; Mon, 28 Mar 2022 12:14:09 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 28 Mar 2022 12:14:09 -0500 From: Segher Boessenkool To: Michael Meissner , gcc-patches@gcc.gnu.org, David Edelsohn , Peter Bergner , Will Schmidt Subject: Re: [PATCH 1/4] Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target 99293. Message-ID: <20220328171409.GM614@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=-3.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 28 Mar 2022 17:15:12 -0000 On Mon, Mar 28, 2022 at 12:26:02PM -0400, Michael Meissner wrote: > However on power9 and power10 it generates: > > ;; vec_splats (vec_extract (src, 0)) > mfvsld 3,34 > mtvsrdd 34,9,9 > > ;; vec_splats (vec_extract (src, 1)) > mfvsrd 9,34 > mtvsrdd 34,9,9 > > This is due to the power9 having the mfvsrld instruction which can extract > either 64-bit element into a GPR. While there are alternatives for both > vector registers and GPR registers, the register allocator prefers to put > DImode into GPR registers. As I said in comment 2 in the PR, it is because we do not have this pattern yet, we only have vec_concat. The instruction combiner tries to use this pattern, but it doesn't exist :-) > +;; Optimize SPLAT of an extract from a V2DF/V2DI vector with a constant element > +;; PR target/99293 > +(define_insn "*vsx_splat_const_extract_" > + [(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa") > + (vec_duplicate:VSX_D > + (vec_select: > + (match_operand:VSX_D 1 "vsx_register_operand" "wa") > + (parallel [(match_operand 2 "const_0_to_1_operand" "n")]))))] > + "VECTOR_MEM_VSX_P (mode)" > +{ > + int which_word = INTVAL (operands[2]); dword, not word. > + if (!BYTES_BIG_ENDIAN) > + which_word = 1 - which_word; > + > + operands[3] = GEN_INT (which_word ? 3 : 0); > + return "xxpermdi %x0,%x1,%x1,%3"; Please use gen_vsx_xxspltd_v2di, instead. Which itself should not use an unspec of course, but that is another patch. > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/pr99293.c > @@ -0,0 +1,36 @@ > +/* { dg-do compile { target powerpc*-*-* } } */ Don't. This is gcc.target/powerpc/ already. > +/* { dg-final { scan-assembler-times "xxpermdi" 4 } } */ \m \M Thanks, Segher