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 1FFAE3854552; Mon, 28 Nov 2022 14:19:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1FFAE3854552 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 2ASEIOQx009341; Mon, 28 Nov 2022 08:18:24 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2ASEINlt009340; Mon, 28 Nov 2022 08:18:23 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 28 Nov 2022 08:18:23 -0600 From: Segher Boessenkool To: Jiufu Guo Cc: "Kewen.Lin" , dje.gcc@gmail.com, linkw@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH V2] rs6000: Support to build constants by li/lis+oris/xoris Message-ID: <20221128141822.GM25951@gate.crashing.org> References: <20221026114052.17713-1-guojiufu@linux.ibm.com> <9331dba8-f346-37e5-3340-055f2c4d9245@linux.ibm.com> <20221125144309.GG25951@gate.crashing.org> <7ebkor21hd.fsf@pike.rch.stglabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ebkor21hd.fsf@pike.rch.stglabs.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP 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: On Mon, Nov 28, 2022 at 11:37:34AM +0800, Jiufu Guo wrote: > Segher Boessenkool writes: > > On Fri, Nov 25, 2022 at 04:11:49PM +0800, Kewen.Lin wrote: > >> on 2022/10/26 19:40, Jiufu Guo wrote: > >> for "li/lis + oris/xoris", I interpreted it into four combinations: > >> > >> li + oris, lis + oris, li + xoris, lis + xoris. > >> > >> not sure just me interpreting like that, but the actual combinations > >> which this patch adopts are: > >> > >> li + oris, li + xoris, lis + xoris. > >> > >> It's a bit off, but not a big deal, up to you to reword it or not. :) > > > > The first two are obvious, but the last one is almost never a good idea, > > there usually are better ways to do the same. I cannot even think of > > any case where this is best? A lis;rl* is always prefered (it can > > optimise better, be combined with other insns). > I understant your point here. The first two: 'li' for lowest 16bits, > 'oris/xoris' for next 16bits. > > While for 'lis + xoris', it may not obvious, because both 'lis' and > 'xoris' operates on 17-31bits. > 'lis + xoris' is for case "32(1) || 1(0) || 15(x) || 16(0)". xoris is > used to clean bit31. This case seems hard to be supported by 'rlxx'. Please put that in a separate patch? First do a patch with just lis;x?oris. They are unrelated and different in almost every way. > I hit to find this case when I analyze what kind of constants can be > build by two instructions. Checked the posssible combinations: > "addi/addis" + "neg/ori/../xoris/rldX/rlwX/../sradi/extswsli"(those > instructions which accept one register and one immediate). > > I also drafted the patch to use "li/lis+rlxx" to build constant. > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601276.html > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601277.html Those seem to do many things in one patch as well :-( It is very hard to review such things, it takes many hours each to do properly. Segher