From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11olkn2010.outbound.protection.outlook.com [40.92.20.10]) by sourceware.org (Postfix) with ESMTPS id A19E93858CD1 for ; Fri, 14 Jul 2023 21:32:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A19E93858CD1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=maskray.me ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HMniHczdfwiMhSiGhesGVqxtnzheWAUwCvuVXgQVr1LmWcrS6l5SU0+1rIr7ZQ6922mI/8M5wl6el4rFvKqWUUPrGGC7G5nL0N2GZQpvQV+6Qu+sNQz4PLLejYEl0EYNZbDtmNbefrN50LjoqPa09c8NeRes8oF3s/JyLSyyFJKnhVPoL+UuxGzKJclDCUp9zywrcYvZAueEp7+DlCbjYesARnDzyMpk9I2YHKLdu35MfCw7zhFqNysAqpvlnhq0W+pmEZg1De38VUv1QsuKcijHJeWH8SqNmf/Zfp9TOEU3KywwNGjjd72AN8qtqTcDG6YgJ37Gm7uTCyEXnNijfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7bVHgk4/lj0fNI30iC9PogVSzuDsox1UPd69aV9pSTc=; b=BYglv9VP3Kafe6oTz9ych7mX8TiFaJlbygZEo8LdEybRAUiKBVzhi6WEQS2p2wn1FsGr0TDoJjWMiAMago47OLr7dGoLCfxH03wlroW6irl0KG6byPb+9xdMg+O2uhjolCxc3VXmdvq29Jrl3UDNmelkSSEa1IUFPYhMhLpUP8OXL/FlLc0uzeuH1MtcEE0b+3ghYIb0JiUUUPHd8yN8Brl8qMQDLQCGUQp8JzGT5Z4KT/ZQ+Nj1vE3AKqWPEb+5vyAKCYsdpt3DbBDDbO6wjB3zxFV6O1UOewbM0sUKT1Wcw+vymx7bv/8KDC8lX97Fz0Gb+Brgwj7VkdGWVBrC8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from MN0PR12MB5761.namprd12.prod.outlook.com (2603:10b6:208:374::6) by DM4PR12MB5390.namprd12.prod.outlook.com (2603:10b6:5:389::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6588.28; Fri, 14 Jul 2023 21:32:24 +0000 Received: from MN0PR12MB5761.namprd12.prod.outlook.com ([fe80::4b7a:6200:879a:3fe1]) by MN0PR12MB5761.namprd12.prod.outlook.com ([fe80::4b7a:6200:879a:3fe1%5]) with mapi id 15.20.6588.027; Fri, 14 Jul 2023 21:32:24 +0000 X-Gm-Message-State: ABy/qLbZi32JXtM01gdSLyBzKUm1Tv/gKrMjvQGXIPYlPbVQVPLr4a8o uMKzdGZb0eoM1n1ie6aXQqaGQp+AvRAZ1MT+W4s= X-Google-Smtp-Source: APBJJlHpJl+cJZy8zs5YMIi1AcJjg6rP2DYUAZD3nWxcjlKGabmc5LZDsab/shMUXFPVAVOT71BobCRxvE0fA2bgNmo= X-Received: by 2002:a17:902:c945:b0:1b8:76ce:9dab with SMTP id i5-20020a170902c94500b001b876ce9dabmr4946183pla.41.1689369930499; Fri, 14 Jul 2023 14:25:30 -0700 (PDT) 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> In-Reply-To: <18227b09-0d51-3e24-b782-5cf74e41e494@suse.com> From: Fangrui Song Date: Fri, 14 Jul 2023 14:25:19 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] RISC-V: re-arrange opcode table for consistent alias handling To: Jan Beulich Cc: Binutils , Nelson Chu , Jessica Clarke , "Stefan O'Rear" , Kito Cheng Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-TMN: [YolFYSdu5o98Ap6Y6sL2tT3gRqb0hhN/] X-ClientProxiedBy: SA0PR11CA0028.namprd11.prod.outlook.com (2603:10b6:806:d3::33) To MN0PR12MB5761.namprd12.prod.outlook.com (2603:10b6:208:374::6) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN0PR12MB5761:EE_|DM4PR12MB5390:EE_ X-MS-Office365-Filtering-Correlation-Id: c4679536-9698-4c61-e579-08db84b1d049 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: s23ZJJNfDWQ3H88yRQOCcVsYgWRp8vG6Bz2m3qJk7F4/OkRBEb2BonXW0uPsCADOiOY+lU7VCqkGxa82pxg/4lNXrSPDeB+NKYztPCPIJTIBfkqppm6cgyYG/Sa+3Gwz+IDPd7yQNmfOW1FBniSlv2dOHsx5/M0H/J/PZ91tKQIywuhkxgvwHzvmy0O6HwB3XUNDKn9l4zHZyeR031Q1HBmbKux2KuW996o3aKBm2ZOG6X7TX0OIZj+hMyJ1ePgu5u4/uwF5h1ToO1Ca3N9kMhUVFiL7sdC120TzMsh49sSTnNKl+3n9KWShw7XpCYGs5Pl0TIoU7t/jMszFrozG+A9jYIOCR8ZU4ze+qOC294YN4yMPrdSUWwyuHOd37Xgf24VlJrT1+HDuRCtnwi/+jh+I1n4wQStc39hlFp1HNYqTn7LxUjyngONvvKuvY5EuyNQYEUcJR1//IBfPYxoxMUTkgCsRi1UuiRrvzB3BOObJEkVVfnfpUYb9pKO0EpL9DZGchm5AhkAIWyRsbYZBnqDxKoZvZiC7wGaA4BRDRqU= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y2FoV25nZk16aHBOdnZzNWowL2ZwRW5VbGMrMElBV3pTSVBzdEs4eXFmQmx3?= =?utf-8?B?eG8wTFh2YmNTQkd2dGhtaElMT2RHbWc0RTJOQWxlSXRsa1JxN2VmVXFJVHlH?= =?utf-8?B?WE9kMm5vOXV2bUtLSWtQZEd5UlhWU1RXWkNMVlNLV0h4SVNvT28vT2RzMDla?= =?utf-8?B?UmQvRDhFRFFna21XYXM4WGEvc2toMHlwbjBsRVN0OU10T2s2UUNxNXNRa3BV?= =?utf-8?B?UXQ0WDM3VmY0dmtWUWRqT1ZJeFd3MmgzUWg5Uk1GN1NvTXhWaTFMdkh0Rm5h?= =?utf-8?B?MzVvN1FsVFNXejNtUFZkNjBjWWw4Vmd4V2o0ajRaOFNXS1Nnb0tzdVR0c1Nx?= =?utf-8?B?Y2sxcEhuVjVDWGVLaHBKQXQ5amZMTzNKMW1xdThvTHBRam1SMDd5TU5ZT05F?= =?utf-8?B?eVNQSWFQWFhXU3paUWpRSU9NZjl4ZCtOc0FhSHRMb1hnYXRtMlg5SWVJTjly?= =?utf-8?B?RUp6QXBOWXR5cmlPWW1IdmI4V25vdDJ1SlE0aFJsV2pCek0zS09xeURUSmNz?= =?utf-8?B?aXlTVGNqNjcyWVNtVmlKVllsa2tockdBUEFrSHptM1owa0FnRHMrSnZOekFV?= =?utf-8?B?SExtRWw1Y25RMzREUElPMWFrNm5EcEg3c0dEWkdNL04zdmpvSGZVVUJNOEFl?= =?utf-8?B?WDFBNlgzVjEwWUxTY0ZxbnEraFFMbUNLSzNjckxuM2FCdzZ6MUl1R2VFVjV5?= =?utf-8?B?QzdkRDA2dDd2M28xT0VDdU5DUXE3dVdKbTlxT3NOcThKQlhIUUNseGs4YTVo?= =?utf-8?B?bHgrR1VlbXpVeTFza0ZEcWNTcU9WY25VL2lXYkU5U0FHcFplc04rSmxpQ0g3?= =?utf-8?B?Qm5VN3hCMHNZamV1UU92cUFBWk1DVUJjdnRKaS9RQThRY2dBM0dJdUZaUUxm?= =?utf-8?B?c2I5dFc2MFNuZDh0RHVOQUpJTG01VUh4cjJmTkFRcTFtSkhEenI3YXpZNTZn?= =?utf-8?B?Z0ZVeGlPcG1TMllFSDFEdDR2VGt2MUQ4Y243amtLZlFBWDl5SERoVnF1MHJZ?= =?utf-8?B?OCt6Ymd2d2hZTXlIZXpYdzU2a3M5QkNGakVoaXJsZVUyaVZsNWcyR3pmTnNR?= =?utf-8?B?SzA2N0U1L0NpQ09ybEthSmhxN1lPZFc5UURMb3lEN3RzbzBrUnZKRmtYYmFM?= =?utf-8?B?SkdqMEFWRXFzMmgwT0pOcGlHS0J1TlUxRTR1dWtlRjdWazFGVm1RQU1oTmla?= =?utf-8?B?QXNQY2swNTU0aGh6ZHZXdFNPMGdLRlgzOVljSUFSbGI4emJVYThPMGRxNW1p?= =?utf-8?B?YXVhaks3MzF4T0Nla0tRTTZYaFQ0eEw3KzNXTXRZNjZlcXo0bGd5bkJNZXUv?= =?utf-8?B?SXNFOW9vTEQ4TVV5SG50WmZUOXpBb1l0UEZXWnBEY0xhYXQ0VEdLVHdlNDVi?= =?utf-8?B?dXBwMGhXdGJDc0ViMGkrSTNpc3B3eW5WUVM4MVF1cXlkakhWcU5NckRMT1dC?= =?utf-8?B?VkRKOUlLT3ovQldOeGh6TEFxOGRjeFFSaHpyaWx0MXJINy9zaVcrM3RnUk11?= =?utf-8?B?NExINW1sSXFKUG80V2RBZmNaRGg2emdiQUhYL01XRzZVZHMrbExYYlVkYnlM?= =?utf-8?Q?jekruLjxgqfq47swWkBS/mtHe7gk5ZTA5Ran3oNyyNBJ1u?= X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-71ea3.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: c4679536-9698-4c61-e579-08db84b1d049 X-MS-Exchange-CrossTenant-AuthSource: MN0PR12MB5761.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2023 21:32:24.6056 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5390 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 Wed, Jul 12, 2023 at 1:15=E2=80=AFAM Jan Beulich wro= te: > > 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 wrote: > >>> > >>> On 15.09.2022 04:30, Nelson Chu wrote: > >>>> On Tue, Sep 13, 2022 at 9:02 PM Jan Beulich wrot= e: > >>>>> --- 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_JAL= R, 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 << O= P_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 << O= P_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_M= V, match_c_add, INSN_ALIAS }, > >>>>> {"move", 0, INSN_CLASS_I, "d,s", MATCH_ADDI, MASK_ADD= I|MASK_IMM, match_opcode, INSN_ALIAS }, > >>>>> {"zext.b", 0, INSN_CLASS_I, "d,s", MATCH_ANDI|ENCODE_IT= YPE_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_AND= I, 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_AND= I, 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_AND= I, 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 a= re > >>> 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 > > > > I apologize as I haven't read all prior discussions. For many > > instructions, the "i" form is written in the ISA manual and prevalent. > > 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 this th= read. > > 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. > 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 exactly > 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 sho= w > > them. >