From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by sourceware.org (Postfix) with ESMTPS id E2B693858CD1 for ; Fri, 14 Jul 2023 22:08:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E2B693858CD1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=fastmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fastmail.com Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 95BAF5C009A; Fri, 14 Jul 2023 18:08:31 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute1.internal (MEProxy); Fri, 14 Jul 2023 18:08:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1689372511; x=1689458911; bh=D3x6ZJ0jgbOKlufu1jGEanStnA8yLZxadT7 pkytSVfo=; b=Z/Y/jQjGt3q8pxogN92lwifGOZkAkWN54SM5sx9UeOerWmYaaa/ OIoUzz5JtFHYFl7UYrMB1B1RsZ2+Krygqg7S+ULhqKAOpzr9WOkw8Ee5H1kysexq RusjWOnoLOawZfEOFR7he52u0FRSdwnpeDV6FjPsrwMULodJAhjHw9yYF1LGkyso b8A39vmVF2PRpFW6JHRDOvxCc5jYRwg5BrkNimvEyoii/uKyR/H2EV+DreDqorYf I7Q4Y/H7JL1vbvWoc6MGKAEswRxOvpSLfhxRThHbgs0IgA69+PNVp3HhQ2wSqSJv bgEv3OcqOrrrnOiz6+ItZBbdtSy7qElGN5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1689372511; x=1689458911; bh=D3x6ZJ0jgbOKlufu1jGEanStnA8yLZxadT7 pkytSVfo=; b=sXdmz1g9EnFQMZx+9zdJ/iuJ1QtdWyXqomwCZcS6sMn+zbAUhoW ON1Lvyv6ym0OD0YauKUro1BsqV2fjKt9GstMjb7PaCVKwxpR1gjQ/cwcZV6v8R8I skhUOn0u98qRGka+qYlgfwrnumcQ/9UiVdgy7aHlXdxlmSROqQrrjBbVp0YhRLTD 65jgkwgNQoCKM0Fb02W0rniB0maAeIWCCKmJw4jCcJ9GasVlA1KH/sqIpgnlo957 3tDpCjI4aN+iUk5+mA9gDu8Q21Nmp7KCSLYuuGtFJ1UvfKkCiYACny6MB6bL+HCe DeJAHnemPRO3Mb3AcEJ/uopaVBJBeQYWlDg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrfeejgddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgfgsehtqhertderreejnecuhfhrohhmpedfufht vghfrghnucfqkdftvggrrhdfuceoshhorhgvrghrsehfrghsthhmrghilhdrtghomheqne cuggftrfgrthhtvghrnhepjeejhefgtdelffevffekhfeujeejteeujeekudehteduleef ueekleevtedtveeinecuffhomhgrihhnpehgihhthhhusgdrtghomhdprhhishgtvhdqrg hsmhdrmhgupdhllhhvmhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehsohhrvggrrhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: i84414492:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 86CA51700089; Fri, 14 Jul 2023 18:08:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-531-gfdfa13a06d-fm-20230703.001-gfdfa13a0 Mime-Version: 1.0 Message-Id: <8c44aaa6-7dac-4b1b-9558-33d15ed9b9f8@app.fastmail.com> In-Reply-To: References: <7cb92a0b-d1ef-e3db-4773-0b6cd5183272@suse.com> <40281e59-659c-044f-0c86-1db77fd17b5c@suse.com> <09666d48-99f0-ae25-ef84-f542da3628ce@suse.com> <18227b09-0d51-3e24-b782-5cf74e41e494@suse.com> Date: Fri, 14 Jul 2023 18:08:09 -0400 From: "Stefan O'Rear" To: "Fangrui Song" , "Jan Beulich" Cc: Binutils , "Nelson Chu" , "Jessica Clarke" , "kito.cheng@sifive.com" Subject: Re: [PATCH 1/3] RISC-V: re-arrange opcode table for consistent alias handling Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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: On Fri, Jul 14, 2023, at 5:25 PM, Fangrui Song wrote: > On Wed, Jul 12, 2023 at 1:15=E2=80=AFAM Jan Beulich wrote: >> >> On 11.07.2023 23:02, Fangrui Song wrote: >> > On Fri, Sep 16, 2022 at 2:53=E2=80=AFAM Nelson Chu wrote: >> >> >> >> On Thu, Sep 15, 2022 at 3:42 PM Jan Beulich wr= ote: >> >>> >> >>> On 15.09.2022 04:30, Nelson Chu wrote: >> >>>> On Tue, Sep 13, 2022 at 9:02 PM Jan Beulich = wrote: >> >>>>> --- a/opcodes/riscv-opc.c >> >>>>> +++ b/opcodes/riscv-opc.c >> >>>>> @@ -290,9 +290,9 @@ const struct riscv_opcode riscv_opcodes[ >> >>>>> {"jalr", 0, INSN_CLASS_I, "d,s,j", MATCH_JALR, MASK= _JALR, match_opcode, INSN_JSR }, >> >>>>> {"j", 0, INSN_CLASS_C, "Ca", MATCH_C_J, MASK_= C_J, match_opcode, INSN_ALIAS|INSN_BRANCH }, >> >>>>> {"j", 0, INSN_CLASS_I, "a", MATCH_JAL, MASK_= JAL|MASK_RD, match_opcode, INSN_ALIAS|INSN_BRANCH }, >> >>>>> +{"jal", 0, INSN_CLASS_I, "a", MATCH_JAL|(X_RA = << OP_SH_RD), MASK_JAL|MASK_RD, match_opcode, INSN_ALIAS|INSN_JSR }, >> >>>>> {"jal", 0, INSN_CLASS_I, "d,a", MATCH_JAL, MASK_= JAL, match_opcode, INSN_JSR }, >> >>>>> {"jal", 32, INSN_CLASS_C, "Ca", MATCH_C_JAL, MAS= K_C_JAL, match_opcode, INSN_ALIAS|INSN_JSR }, >> >>>>> -{"jal", 0, INSN_CLASS_I, "a", MATCH_JAL|(X_RA = << OP_SH_RD), MASK_JAL|MASK_RD, match_opcode, INSN_ALIAS|INSN_JSR }, >> >>>>> {"call", 0, INSN_CLASS_I, "d,c", (X_T1 << OP_SH_R= S1), (int) M_CALL, match_never, INSN_MACRO }, >> >>>>> {"call", 0, INSN_CLASS_I, "c", (X_RA << OP_SH_R= S1)|(X_RA << OP_SH_RD), (int) M_CALL, match_never, INSN_MACRO }, >> >>>>> {"tail", 0, INSN_CLASS_I, "c", (X_T1 << OP_SH_R= S1), (int) M_CALL, match_never, INSN_MACRO }, >> >>>>> @@ -310,13 +310,13 @@ const struct riscv_opcode riscv_opcodes[ >> >>>>> {"move", 0, INSN_CLASS_C, "d,CV", MATCH_C_MV, MASK= _C_MV, match_c_add, INSN_ALIAS }, >> >>>>> {"move", 0, INSN_CLASS_I, "d,s", MATCH_ADDI, MASK= _ADDI|MASK_IMM, match_opcode, INSN_ALIAS }, >> >>>>> {"zext.b", 0, INSN_CLASS_I, "d,s", MATCH_ANDI|ENCOD= E_ITYPE_IMM (255), MASK_ANDI | MASK_IMM, match_opcode, INSN_ALIAS }, >> >>>>> -{"andi", 0, INSN_CLASS_C, "Cs,Cw,Co", MATCH_C_ANDI, MA= SK_C_ANDI, match_opcode, INSN_ALIAS }, >> >>>>> -{"andi", 0, INSN_CLASS_I, "d,s,j", MATCH_ANDI, MASK= _ANDI, match_opcode, 0 }, >> >>>>> {"and", 0, INSN_CLASS_C, "Cs,Cw,Ct", MATCH_C_AND, MAS= K_C_AND, match_opcode, INSN_ALIAS }, >> >>>>> {"and", 0, INSN_CLASS_C, "Cs,Ct,Cw", MATCH_C_AND, MAS= K_C_AND, match_opcode, INSN_ALIAS }, >> >>>>> {"and", 0, INSN_CLASS_C, "Cs,Cw,Co", MATCH_C_ANDI, MA= SK_C_ANDI, match_opcode, INSN_ALIAS }, >> >>>>> {"and", 0, INSN_CLASS_I, "d,s,t", MATCH_AND, MASK_= AND, match_opcode, 0 }, >> >>>>> {"and", 0, INSN_CLASS_I, "d,s,j", MATCH_ANDI, MASK= _ANDI, match_opcode, INSN_ALIAS }, >> >>>>> +{"andi", 0, INSN_CLASS_C, "Cs,Cw,Co", MATCH_C_ANDI, MA= SK_C_ANDI, match_opcode, INSN_ALIAS }, >> >>>>> +{"andi", 0, INSN_CLASS_I, "d,s,j", MATCH_ANDI, MASK= _ANDI, match_opcode, 0 }, >> >>>> >> >>>> Doesn't ANDI a base instruction? >> >>> >> >>> Of course. Like for all aliases, there is a corresponding base >> >>> instruction. I guess I simply don't understand what you mean to >> >>> express with the question. >> >>> >> >>>> The operand "d,s,j" of AND is an >> >>>> alias of ANDI, so the original order seems correct. Always dump= *.i >> >>>> instructions to the non-i type looks weird, and llvm-dump seems = has >> >>>> the same behavior as current GNU objdump. >> >>>> >> >>>> % cat tmp.s >> >>>> and a0, a1, 0x10 >> >>>> % riscv64-unknown-elf-as tmp.s -o tmp.o >> >>>> % riscv64-unknown-elf-objdump -d tmp.o >> >>>> >> >>>> tmp.o: file format elf64-littleriscv >> >>>> >> >>>> >> >>>> Disassembly of section .text: >> >>>> >> >>>> 0000000000000000 <.text>: >> >>>> >> >>>> 0: 0105f513 and a0,a1,16 >> >>> >> >>> What's weird about that? And if that's weird, would you mind spel= ling >> >>> out the conditions under which aliases are to be preferred over b= ase >> >>> instructions when disassembling? There actually is a "These alias= es are >> >>> for assembly but not disassembly" comment somewhere in the file, >> >>> clarifying for two of the aliases that they ought to come after t= heir >> >>> base insns. But for all other aliases which aren't simply a diffe= rent >> >>> (but not shorter) name for the same insn (e.g. "bgt" vs "blt") I'd >> >>> assume the aliases should be preferred, for the reason stated in = the >> >>> patch description. That said - I can see it being a matter of tas= te >> >>> for i vs , but if so this should be spelled out somew= here. >> >> >> >> Yeah, that's what I worried about. At the beginning, I think dump= ing >> >> a base instruction as another base instruction looks weird. But t= hese >> >> days I also noticed that - we also dump compressed instructions as >> >> base i without "c." prefixes, so why I feel weird is just that I'm >> >> used to it because of historical behavior. I have no objection to >> >> this, so please go ahead if there are no objections for a period of >> >> time. But if there are any objections, then we probably can mark >> >> these aliases by something like INSN_ALIAS_CANNOT_DUMP in the opco= de >> >> table, and that's what Kito suggested to me before, but I didn't t= hink >> >> it was a serious problem at the time. >> >> >> >> Thanks >> >> Nelson >> > >> > I apologize as I haven't read all prior discussions. For many >> > instructions, the "i" form is written in the ISA manual and prevale= nt. >> >> Why "prevalent"? The "i"-less forms are mentioned there as well, aren= 't >> they? Then why not use them ... > > I think aliases like "add rd,rs,imm" (without "i") should be treated > as deprecated aliases that we keep just for compatibility. > We should not endorse the use cases by making objdump -d "prefer" this= form. > > When I brought up the topic in the #riscv channel on libera.chat, I > got a lot of complaints about having these "deprecated" aliases from > folks, including courmisch, jrtc27, muurkha, sorear. > As I happen to know two folks' email addresses, I have CCed them in th= is thread. > >> > I wonder whether we can give these add/and/xor/etc without "i" lower >> > priority so that objdump -d will not show them, even without using = -M >> > no-aliases. >> >> ... unless use of aliases was suppressed? In other arches' assembly >> that I know (to some degree) and which knows the concept of aliases, >> aliases are typically the preferred way of disassembling, for >> typically producing easier to grok output. > > AIUI aliases for other architectures are indeeded preferred (use my > understanding of llvm-objdump -d output). > This RISC-V case is not, though. The aliases that are documented in [1] are preferred for use in disassem= bly. The other aliases, which gas supports for compatibility with old version= s of itself but which were never part of any spec, are not preferred. -s [1]: https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv= -asm.md >> There are other aspects to consider here, related to the handling of >> equates in assembly sources. I did bring this up before, but it feels >> like a minefield - it first would need firmly establishing what exact= ly >> assembler behavior is intended to be. Aiui no-one has properly thought >> of this, including for the (surprisingly similar) handling in tc-mips= .c >> (making me guess that RISC-V code may have been derived from that). >> >> Jan > > My knowledge about GNU assembler is quite limited... > I hope that other RISC-V folks can answer this question. > > >> > % cat b.s >> > add a0,a1,13 >> > and a2,a3,4 >> > xor a2,a3,4 >> > or a2,a3,4 >> > sll a2,a3,4 >> > % riscv64-linux-gnu-gcc -c b.s >> > % ~/Dev/binutils-gdb/out/riscv64/binutils/objdump -d b.o >> > >> > b.o: file format elf64-littleriscv >> > >> > >> > Disassembly of section .text: >> > >> > 0000000000000000 <.text>: >> > 0: 00d58513 add a0,a1,13 >> > 4: 0046f613 and a2,a3,4 >> > 8: 0046c613 xor a2,a3,4 >> > c: 0046e613 or a2,a3,4 >> > 10: 00469613 sll a2,a3,0x4 >> > >> > >> > When LLVM integrated assembler added these aliases >> > (https://reviews.llvm.org/D50046), these instructions are assigned a >> > low priority "let EmitPriority =3D 0" so llvm-objdump -d will never= show >> > them. >>