From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by sourceware.org (Postfix) with ESMTPS id 291253856964 for ; Fri, 16 Sep 2022 09:53:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 291253856964 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-oi1-x232.google.com with SMTP id j188so3188520oih.0 for ; Fri, 16 Sep 2022 02:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=yU6+yEb0PJ8LuCIpp19Erk5QO6Q5UAL7OKfiJ0Db7vQ=; b=kGxizhgkE9GT5g6gcBV/Qz3/3WqPd6YnI4DL26Cq4K8vWoG9QA4ABEN8cxscIsTSDU ZXc+hTNvj55/WQINFUFtV+1nsn4+ILr3TAgAf4SkAwcYKjXkatfufvuiIEN4NLOiATss sN6FIjGkG6VMNzrAnYbBXcwwbamYXbCUR35fhdOw6qxDVDLL6tlSoAgRAMB9/JuDoOp8 eu+WIw7QYRKXymMOPBBCIFnFDDrwFTxDO/ymeXtG3qQhYZo5OrAGF6mfbMB5Fk08hlXR WvAwGxa+lOJ621vNFdRNtlZF7aPeABWtx8FwLHTtIJ6mMdx7Em4adpRDbwkunY8xGn67 TmHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=yU6+yEb0PJ8LuCIpp19Erk5QO6Q5UAL7OKfiJ0Db7vQ=; b=uIiEKgg+jGgZprTPxgq1M6AnbR6N+aKq4EwsXS6kG/T51Y6MzdUgyXQexo0NQAx+Lv j1kfj1ZYS9jgPbVfnPJXuP73BuoLTK/NONWO8oHiqNIFs7me331TF37y+r/XO1X2lOew tlcEBNIr3e0hAyppDeFfRwiuuVAacnfi9YoKYEgN9ogXGPLgViIwWIAxJnl8wpmhj1dZ AgrG2+h4xJYgLqx8LJ7cuKVDaF6mLUc4aUJped85KeFuyjV6oeVd7ClqBVgAkEQUfX56 PqlH4ve04nIhKd8aRaUBfnLg6xrXAKXmXMr/5ClHUiOSOBULtwiLrOxtfm3ICVzALx00 DcpA== X-Gm-Message-State: ACrzQf2D8R+hAtDdgvoVEEGc83XIsrdfW6ZMsYU1ObTn2PH4rH9jhm9L Vrq4PMgnkpmXujaiD/a4fcckr7swtNQl5LKwX42Opg== X-Google-Smtp-Source: AMsMyM7u+MIXx8JYgYRDy84XLoPkWuWDZCzPaoo8zUG/J4lcyh8VKy9x1C0UK1NrqxjGzS/0LuWg34jRuVT7negMk/g= X-Received: by 2002:a05:6808:1884:b0:344:cc03:c64d with SMTP id bi4-20020a056808188400b00344cc03c64dmr1928078oib.107.1663322015476; Fri, 16 Sep 2022 02:53:35 -0700 (PDT) MIME-Version: 1.0 References: <7cb92a0b-d1ef-e3db-4773-0b6cd5183272@suse.com> <40281e59-659c-044f-0c86-1db77fd17b5c@suse.com> <09666d48-99f0-ae25-ef84-f542da3628ce@suse.com> In-Reply-To: <09666d48-99f0-ae25-ef84-f542da3628ce@suse.com> From: Nelson Chu Date: Fri, 16 Sep 2022 17:53:24 +0800 Message-ID: Subject: Re: [PATCH 1/3] RISC-V: re-arrange opcode table for consistent alias handling To: Jan Beulich Cc: Binutils , Palmer Dabbelt , Andrew Waterman , Jim Wilson Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,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: On Thu, Sep 15, 2022 at 3:42 PM Jan Beulich wrote: > > 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, MASK_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_RS1), (int) M_CALL, match_never, INSN_MACRO }, > >> {"call", 0, INSN_CLASS_I, "c", (X_RA << OP_SH_RS1)|(X_RA << OP_SH_RD), (int) M_CALL, match_never, INSN_MACRO }, > >> {"tail", 0, INSN_CLASS_I, "c", (X_T1 << OP_SH_RS1), (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|ENCODE_ITYPE_IMM (255), MASK_ANDI | MASK_IMM, match_opcode, INSN_ALIAS }, > >> -{"andi", 0, INSN_CLASS_C, "Cs,Cw,Co", MATCH_C_ANDI, MASK_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, MASK_C_AND, match_opcode, INSN_ALIAS }, > >> {"and", 0, INSN_CLASS_C, "Cs,Ct,Cw", MATCH_C_AND, MASK_C_AND, match_opcode, INSN_ALIAS }, > >> {"and", 0, INSN_CLASS_C, "Cs,Cw,Co", MATCH_C_ANDI, MASK_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, MASK_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 spelling > out the conditions under which aliases are to be preferred over base > instructions when disassembling? There actually is a "These aliases are > for assembly but not disassembly" comment somewhere in the file, > clarifying for two of the aliases that they ought to come after their > base insns. But for all other aliases which aren't simply a different > (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 taste > for i vs , but if so this should be spelled out somewhere. Yeah, that's what I worried about. At the beginning, I think dumping a base instruction as another base instruction looks weird. But these 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 opcode table, and that's what Kito suggested to me before, but I didn't think it was a serious problem at the time. Thanks Nelson > > % llvm-objdump -d tmp.o > > > > tmp.o: file format elf64-littleriscv > > > > Disassembly of section .text: > > > > 0000000000000000 <$x>: > > 0: 13 f5 05 01 andi a0, a1, 16 > > I don't think I view llvm as a "canonical reference". Perhaps they merely > followed the GNU behavior? > > Jan