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 4391F38582BC; Tue, 21 Jun 2022 18:11:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4391F38582BC 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 25LIASMm010224; Tue, 21 Jun 2022 13:10:28 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 25LIASsT010223; Tue, 21 Jun 2022 13:10:28 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 21 Jun 2022 13:10:28 -0500 From: Segher Boessenkool To: Jiufu Guo Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, amodra@gmail.com Subject: Re: [PATCH V2]rs6000: Store complicated constant into pool Message-ID: <20220621181028.GR25951@gate.crashing.org> References: <20220614132355.117887-1-guojiufu@linux.ibm.com> <20220614223421.GB25951@gate.crashing.org> <20220615174441.GD25951@gate.crashing.org> <7eczf99hi2.fsf@pike.rch.stglabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7eczf99hi2.fsf@pike.rch.stglabs.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, KAM_SHORT, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2022 18:11:30 -0000 Hi! On Thu, Jun 16, 2022 at 03:47:49PM +0800, Jiufu Guo wrote: > Segher Boessenkool writes: > >> >> --- a/gcc/testsuite/gcc.target/powerpc/medium_offset.c > >> >> +++ b/gcc/testsuite/gcc.target/powerpc/medium_offset.c > >> >> @@ -1,7 +1,7 @@ > >> >> /* { dg-do compile { target { powerpc*-*-* } } } */ > >> >> /* { dg-require-effective-target lp64 } */ > >> >> /* { dg-options "-O" } */ > >> >> -/* { dg-final { scan-assembler-not "\\+4611686018427387904" } } */ > >> >> +/* { dg-final { scan-assembler-times {\msldi|pld\M} 1 } } */ > >> > > >> > Why? This is still better generated in code, no? It should never be > >> > loaded from a constant pool (it is hex 4000_0000_0000_0000, easy to > >> > construct with just one or two insns). > >> > >> For p8/9, two insns "lis 0x4000+sldi 32" are used: > >> addis %r3,%r2,.LANCHOR0@toc@ha > >> addi %r3,%r3,.LANCHOR0@toc@l > >> lis %r9,0x4000 > >> sldi %r9,%r9,32 > >> add %r3,%r3,%r9 > >> blr > > > > That does not mean putting this constant in the constant pool is a good > > idea at all, of course. > > > >> On p10, as expected, 'pld' would be better than 'lis+sldi'. > > > > Is it? > > With simple cases, it shows 'pld' seems better. For perlbench, it may > also indicate this. But I did not test this part separately. > As you suggested, I will collect more data to check this change. Look at p10 for example. There can be only two pld's concurrently, and they might miss in the cache as well (not likely hopefully, but it is costly). pld is between 4 and 6 cycles latency, so that is never better than 1+1 to 3+3 what the addi+rldicr (li+sldi) are, and easily worse. If you really see loads being better than two simple integer insns, we need to rethink more :-/ Segher