From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id E00973858C5E; Mon, 28 Nov 2022 03:37:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E00973858C5E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AS0CPkH012294; Mon, 28 Nov 2022 03:37:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : references : date : in-reply-to : message-id : content-type : mime-version; s=pp1; bh=C98kKO5mXAHKuir8y18kOrZ3A08a2kqL1J9MCTwBgHY=; b=oosmGh+Pm8KMBQe3XD/NSjdH67ZCnmpIfcVJ6jC7bMAmwWgwfyvlUZbYs+z0TbsC/eQD +wFKane9yhTdTJfmZniSbB5AJ2Oq/+9HWy/tXs2zCfMxLNxev1HIrmd93+C9LH8rQXog V4vbmLGpdH8fu6ChjV1wP8k0SirFsL7tE7spoWrWZzzjLAr4xiPMwZB7neAuL2pBWwwa oA4T1/ZZoXStd4FIGpzVNLitHlCZyBhAUDUaV6fHre8LegXtBd9KKb9WDW1Z4fdn5ADl X2PjoVrwWA1ss6UagIjvD9WqvMCb+whIiz3MSaj5qA0NPflR71NqbyQVV7NCDMRTIHAI VA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m3vpkm6dv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 03:37:40 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2AS3MXWf023216; Mon, 28 Nov 2022 03:37:40 GMT Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m3vpkm6dm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 03:37:40 +0000 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2AS3ZR6L001120; Mon, 28 Nov 2022 03:37:38 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma01wdc.us.ibm.com with ESMTP id 3m3ae9326m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 03:37:38 +0000 Received: from smtpav05.dal12v.mail.ibm.com ([9.208.128.132]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2AS3bdHQ42074832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Nov 2022 03:37:40 GMT Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93F375804C; Mon, 28 Nov 2022 03:37:37 +0000 (GMT) Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 59C1858067; Mon, 28 Nov 2022 03:37:37 +0000 (GMT) Received: from pike (unknown [9.5.12.127]) by smtpav05.dal12v.mail.ibm.com (Postfix) with ESMTPS; Mon, 28 Nov 2022 03:37:37 +0000 (GMT) From: Jiufu Guo To: Segher Boessenkool 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 References: <20221026114052.17713-1-guojiufu@linux.ibm.com> <9331dba8-f346-37e5-3340-055f2c4d9245@linux.ibm.com> <20221125144309.GG25951@gate.crashing.org> Date: Mon, 28 Nov 2022 11:37:34 +0800 In-Reply-To: <20221125144309.GG25951@gate.crashing.org> (Segher Boessenkool's message of "Fri, 25 Nov 2022 08:43:09 -0600") Message-ID: <7ebkor21hd.fsf@pike.rch.stglabs.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: fXBmfYMve_yDyyWZRqPeeZyi2DCpTeyb X-Proofpoint-GUID: TAXhDeP-AIRIlsjx_ldeSEvIf87u5Hpq X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-28_03,2022-11-25_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 impostorscore=0 mlxscore=0 malwarescore=0 adultscore=0 spamscore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 priorityscore=1501 clxscore=1015 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211280026 X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 Segher! Thanks a lot for your comments! Segher Boessenkool writes: > Hi guys, > > 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'. 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 > >> > + HOST_WIDE_INT orig_c = c; > > If you ever feel you need a variable to hold an "orig" value, that is a > good hint that you should restructure the code a bit, perhaps even > factor it. That often is overdue (like here), not caused by you, but > you could help solve it ;-) > > (This is what made this patch hard to review, btw). You are right. Thanks for point out this! > >> > gen_rtx_IOR (DImode, copy_rtx (temp), >> > GEN_INT (ud1))); >> > } >> > + else if ((ud4 == 0xffff && ud3 == 0xffff) >> > + && ((ud1 & 0x8000) || (ud1 == 0 && !(ud2 & 0x8000)))) >> > + { >> > + temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode); >> > + >> > + HOST_WIDE_INT imm = (ud1 & 0x8000) ? ((ud1 ^ 0x8000) - 0x8000) >> > + : ((ud2 << 16) - 0x80000000); > > We really should have some "hwi::sign_extend (ud1, 16)" helper function, > heh. Maybe there already is? Ah, "sext_hwi". Fixing that up > everywhere in this function is preapproved. Great, thanks! > >> > + else >> > + { >> > + emit_move_insn (temp, >> > + GEN_INT (((ud2 << 16) ^ 0x80000000) - 0x80000000)); >> > + if (ud1 != 0) >> > + emit_move_insn (temp, gen_rtx_IOR (DImode, temp, GEN_INT (ud1))); >> > + emit_move_insn (dest, >> > + gen_rtx_ZERO_EXTEND (DImode, >> > + gen_lowpart (SImode, temp))); >> > + } > > Why this? Please just write it in DImode, do not go via SImode? Thanks for catch this. Yes, gen_lowpart with DImode would be ok. > >> > --- /dev/null >> > +++ b/gcc/testsuite/gcc.target/powerpc/pr106708.h >> > @@ -0,0 +1,9 @@ >> > +/* Test constants which can be built by li/lis + oris/xoris */ >> > +void __attribute__ ((__noinline__, __noclone__)) foo (long long *arg) >> > +{ >> > + *arg++ = 0x98765432ULL; >> > + *arg++ = 0xffffffff7cdeab55ULL; >> > + *arg++ = 0xffffffff65430000ULL; >> > +} > > Use noipa please (it is shorter, simpler, and covers more :-) ) Thanks! > > Could you comment what exact instructions are expected? > li;xoris and li;xoris and lis;xoris I guess? It helps if you just tell > the reader here. Sure, thanks! > > The li;oris and li;xoris parts look good. > BR, Jeff (Jiufu) > > Segher