From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) by sourceware.org (Postfix) with ESMTPS id A4B9C3858D37 for ; Thu, 29 Jun 2023 12:38:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A4B9C3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=xen0n.name Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xen0n.name DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1688042293; bh=kBz1uMIjuLQWqVcsJDNkexqGrEY16OmfOBVJYadj0Qw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Rvr+xkArXgY8omAlucHqWAGESF8F4wGOi+tel5hF/tC9KwXIwJ7mdmXlrDFzygY3K WpiezbE7Vwr5yrz8RUw37NKHlIWMWbYY3i0CSsgI7Xl4u3SyKic3xqu+JxQ8YrS03d 741fMN20vvC9a8W3T9z1NyPA/TUokMrZalmzqm6Y= Received: from [100.100.34.13] (unknown [220.248.53.61]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailbox.box.xen0n.name (Postfix) with ESMTPSA id A21FA600BD; Thu, 29 Jun 2023 20:38:12 +0800 (CST) Message-ID: Date: Thu, 29 Jun 2023 20:38:11 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH] LoongArch: gas: Add LVZ and LBT instructions support Content-Language: en-US To: mengqinggang , binutils@sourceware.org Cc: xuchenghua@loongson.cn, chenglulu@loongson.cn, liuzhensong@loongson.cn, xry111@xry111.site, i.swmail@xen0n.name, maskray@google.com References: <20230629090831.2579210-1-mengqinggang@loongson.cn> From: WANG Xuerui In-Reply-To: <20230629090831.2579210-1-mengqinggang@loongson.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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, Upon closer look (while compiling the loongarch-opcodes data)... On 2023/6/29 17:08, mengqinggang wrote: > [snip] > + > +static struct loongarch_opcode loongarch_lbt_opcodes[] = > +{ > + /* match, mask, name, format, macro, include, exclude, pinfo. */ > + [snip] > + {0x00368000, 0xffffc3e0, "setx86j", "r0:5,u10:4", 0, 0, 0, 0}, > + {0x00007800, 0xfffffc00, "setx86loope", "r0:5,r5:5", 0, 0, 0, 0}, > + {0x00007c00, 0xfffffc00, "setx86loopne", "r0:5,r5:5", 0, 0, 0, 0}, These 3 instructions are named "setx86..." instead of the obvious "x86set...". This is especially inconsistent, because we even have... > + {0x005c0000, 0xfffc03e0, "x86mfflag", "r0:5,u10:8", 0, 0, 0, 0}, > + {0x005c0020, 0xfffc03e0, "x86mtflag", "r0:5,u10:8", 0, 0, 0, 0}, > + {0x00007400, 0xffffffe0, "x86mftop", "r0:5", 0, 0, 0, 0}, > + {0x00007000, 0xffffff1f, "x86mttop", "u5:3", 0, 0, 0, 0}, > + {0x00008009, 0xffffffff, "x86inctop", "", 0, 0, 0, 0}, > + {0x00008029, 0xffffffff, "x86dectop", "", 0, 0, 0, 0}, > + {0x00008008, 0xffffffff, "x86settm", "", 0, 0, 0, 0}, This, which is "x86set...". We probably don't want "setx86" and "x86set" to co-exist, and the trivial fix would be adding "x86setj" "x86setloope" and "x86setloopne". > + {0x00008028, 0xffffffff, "x86clrtm", "", 0, 0, 0, 0}, > + {0x00580000, 0xfffc0000, "x86settag", "r0:5,u5:5,u10:8", 0, 0, 0, 0}, > + {0x00370010, 0xffff8010, "armadd.w", "r5:5,r10:5,u0:4", 0, 0, 0, 0}, > + {0x00378010, 0xffff8010, "armsub.w", "r5:5,r10:5,u0:4", 0, 0, 0, 0}, > + {0x00380010, 0xffff8010, "armadc.w", "r5:5,r10:5,u0:4", 0, 0, 0, 0}, > + {0x00388010, 0xffff8010, "armsbc.w", "r5:5,r10:5,u0:4", 0, 0, 0, 0}, > + {0x00390010, 0xffff8010, "armand.w", "r5:5,r10:5,u0:4", 0, 0, 0, 0}, > + {0x00398010, 0xffff8010, "armor.w", "r5:5,r10:5,u0:4", 0, 0, 0, 0}, > + {0x003a0010, 0xffff8010, "armxor.w", "r5:5,r10:5,u0:4", 0, 0, 0, 0}, > + {0x003fc01c, 0xffffc01f, "armnot.w", "r5:5,u10:4", 0, 0, 0, 0}, > + {0x003a8010, 0xffff8010, "armsll.w", "r5:5,r10:5,u0:4", 0, 0, 0, 0}, > + {0x003b0010, 0xffff8010, "armsrl.w", "r5:5,r10:5,u0:4", 0, 0, 0, 0}, > + {0x003b8010, 0xffff8010, "armsra.w", "r5:5,r10:5,u0:4", 0, 0, 0, 0}, > + {0x003c0010, 0xffff8010, "armrotr.w", "r5:5,r10:5,u0:4", 0, 0, 0, 0}, > + {0x003c8010, 0xffff8010, "armslli.w", "r5:5,u10:5,u0:4", 0, 0, 0, 0}, > + {0x003d0010, 0xffff8010, "armsrli.w", "r5:5,u10:5,u0:4", 0, 0, 0, 0}, > + {0x003d8010, 0xffff8010, "armsrai.w", "r5:5,u10:5,u0:4", 0, 0, 0, 0}, > + {0x003e0010, 0xffff8010, "armrotri.w", "r5:5,u10:5,u0:4", 0, 0, 0, 0}, > + {0x003fc01f, 0xffffc01f, "armrrx.w", "r5:5,u10:4", 0, 0, 0, 0}, > + {0x00364000, 0xffffc000, "armmove", "r0:5,r5:5,u10:4", 0, 0, 0, 0}, > + {0x003fc01d, 0xffffc01f, "armmov.w", "r5:5,u10:4", 0, 0, 0, 0}, > + {0x003fc01e, 0xffffc01f, "armmov.d", "r5:5,u10:4", 0, 0, 0, 0}, > + {0x005c0040, 0xfffc03e0, "armmfflag", "r0:5,u10:8", 0, 0, 0, 0}, > + {0x005c0060, 0xfffc03e0, "armmtflag", "r0:5,u10:8", 0, 0, 0, 0}, > + {0x0036c000, 0xffffc3e0, "setarmj", "r0:5,u10:4", 0, 0, 0, 0}, Similarly here; "armsetj" would be more consistent with the rest. Again, IMO it would be okay to temporarily keep the old names around for some time if you want too, but ideally new names should be added so surprise for users is minimized.