From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 79BFF3858D3C; Mon, 28 Nov 2022 07:52:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 79BFF3858D3C 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 (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AS62sTU031577; Mon, 28 Nov 2022 07:52:06 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=8GabN3Ibsk82CV+hI1hHOWdF0Dh/rYC92gfO4tsbRj4=; b=brLljQmRBGzTW2yK6AJRsNtudQovZSENyFK5I1c2P83ZaHYDT75jvYg98BxwVHCggHwE 1dCVdl9bpsZ0XJNk9pVo4Bjyf6wQFF16/47SpBrOmOWspZW6qF5T8GRNZin4uzPNMVlM 0JV7W3f1yo8SDkX3W5M73nMYlgbTmn3GD1M40QSxSmtawlRNq1x210d2vBOYPlP9JblQ UiLe9AmyE+fKGU3TDrvKqaI+zAfTbsLddPeNfWVP+boEmWB2lsjFoUV0jdXj51nuu49M jfsl+oOD4Au2fzkp72smKXbGxHlE4yScoJ+peQAO2xRet8w99pDjD1E17JjS0alGXn/H Zg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m3vn70xgv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 07:52:05 +0000 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2AS7lcNw018559; Mon, 28 Nov 2022 07:52:05 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m3vn70xgq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 07:52:05 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2AS7o5Zn004587; Mon, 28 Nov 2022 07:52:04 GMT Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by ppma02dal.us.ibm.com with ESMTP id 3m3ae975rp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 07:52:04 +0000 Received: from smtpav06.wdc07v.mail.ibm.com ([9.208.128.115]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2AS7q3DT10093078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Nov 2022 07:52:03 GMT Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 17C2158071; Mon, 28 Nov 2022 07:52:03 +0000 (GMT) Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A011E5803F; Mon, 28 Nov 2022 07:52:02 +0000 (GMT) Received: from pike (unknown [9.5.12.127]) by smtpav06.wdc07v.mail.ibm.com (Postfix) with ESMTPS; Mon, 28 Nov 2022 07:52:02 +0000 (GMT) From: Jiufu Guo To: Jiufu Guo via Gcc-patches Cc: Segher Boessenkool , "Kewen.Lin" , dje.gcc@gmail.com, linkw@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> <7ebkor21hd.fsf@pike.rch.stglabs.ibm.com> Date: Mon, 28 Nov 2022 15:51:59 +0800 In-Reply-To: <7ebkor21hd.fsf@pike.rch.stglabs.ibm.com> (Jiufu Guo via Gcc-patches's message of "Mon, 28 Nov 2022 11:37:34 +0800") Message-ID: <7e5yez1ppc.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-GUID: 6iADh7mqprspz0VdTQw8BOGD8o5la8xn X-Proofpoint-ORIG-GUID: 09wwUlxy91tCpZ3B30RS9eaNqY4W85zo 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_06,2022-11-25_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 mlxscore=0 suspectscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=999 phishscore=0 clxscore=1015 bulkscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211280058 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: Jiufu Guo via Gcc-patches writes: > 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. Oh, Sorry. DImode can not be used here. The genreated pattern with DImode can not be recognized. Using SImode is to match 'rlwxx'. BR, Jeff (Jiufu) >> >>> > --- /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