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 B659E3854816; Fri, 11 Jun 2021 20:17:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B659E3854816 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail 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 15BKGCrE014698; Fri, 11 Jun 2021 15:16:13 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 15BKGCI7014697; Fri, 11 Jun 2021 15:16:12 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 11 Jun 2021 15:16:12 -0500 From: Segher Boessenkool To: Xionghu Luo Cc: wschmidt@linux.ibm.com, gcc-patches@gcc.gnu.org, linkw@gcc.gnu.org, dje.gcc@gmail.com Subject: Re: [PATCH] rs6000: Support doubleword swaps removal in rot64 load store [PR100085] Message-ID: <20210611201612.GR18427@gate.crashing.org> References: <20210602081932.2683429-1-luoxhu@linux.ibm.com> <20210602222003.GJ18427@gate.crashing.org> <20210603203107.GZ18427@gate.crashing.org> <20210608201129.GA18427@gate.crashing.org> <6cae0a56-dcd9-11b9-b9d6-aa4e24b86026@linux.ibm.com> <20210609162420.GG18427@gate.crashing.org> <65101998-c29d-b514-9c69-732b5c6d2cf8@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65101998-c29d-b514-9c69-732b5c6d2cf8@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Fri, 11 Jun 2021 20:17:14 -0000 On Thu, Jun 10, 2021 at 03:11:08PM +0800, Xionghu Luo wrote: > On 2021/6/10 00:24, Segher Boessenkool wrote: > >> "!BYTES_BIG_ENDIAN && TARGET_VSX && reload_completed && !TARGET_P9_VECTOR > >> && !altivec_indexed_or_indirect_operand (operands[0], mode)" > >> [(const_int 0)] > >> { > >> rs6000_emit_le_vsx_permute (operands[1], operands[1], mode); > >> rs6000_emit_le_vsx_permute (operands[0], operands[1], mode); > >> rs6000_emit_le_vsx_permute (operands[1], operands[1], mode); > >> DONE; > >> }) > > > > So it seems like it is only 3 insns in the very unlucky case? Normally > > it will end up as just one simple store? > > I am afraid there is not "simple store" for *TImode on P8LE*. There is only > stxvd2x that rotates the element(stvx requires memory to be aligned, not > suitable pattern), so every vsx_le_perm_store_v1ti must be split to 3 > instructions for alternative 0, it seems incorrect to force the cost to be 4. Often it could be done as just two insns though? If the value stored is not used elsewhere? So we could make the first alternative cost 8 then as well, which will also work out for combine, right? Alternatively we could have what is now the second alternative be the first, if that is realistic -- that one already has cost 8 (it is just two machine instructions). Segher