From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11olkn2096.outbound.protection.outlook.com [40.92.18.96]) by sourceware.org (Postfix) with ESMTPS id 3DC793858D1E for ; Tue, 11 Jul 2023 21:02:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3DC793858D1E 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=oKXEeQr1QL8+gUp9onyOzkTM3W4b9IQvefwgcohrN+HBXp6zyA+XkLnoZ5iX3XrXySMTvlEjuf1ODKm3CsRy0CstL0z5h9DErYqvI52viO50d6Hjk0Al8xxwQ1nxCdxZBjgVA2NQZLbYfFJIX0fV8mFHNFBVv3K3idb4Leer8eRXvj8uumSQdvtwcWcumNgBehOE15NmAAm65V9ijAXxxqk8onvdz7uaUlyrNbmKJgSTzHD2NNT9elFkmqD3hU7jCD9hb0ltkaaLqdtzGiVvxOiY13DDj/vPKDAfLD1Zms242VimwulXpOI7TqS62bhTf5c1BxhYXpwi35MGImVWsA== 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=hvzjtxdTifP4M4y5EtOIrpgqo5zEXYZTVrd0oTxaO9w=; b=cOrhAeoA8H+jqkyEY7CL89cYswc22vPQ/fQaw1r94cYnXeoZGC3q1zk8p869ysFcaESPMOaAtdtnu3Ve7oJ9LVuiuFHOkg78HdL6GKiiDJyu1/3IhhICwuOl27QYb0ltEAmjt1EDuYN1fhclKdiZ/+/IR0AIvTb2js8jkqDHps00Ul0t5DgtrfcCc5K160OshJvUJr3ABgK+xe+s3M5XMbU1duALUjdTcxjNJOt/DT/ofScBhIMVDnd4y8LSPyuTeGjbHW4OJa1+qkJaWajk6S9OqeQ/EV6u5vaFPS8RD2viQ42m2fCvN93GbLSGuzolb9ZLM9CmS6YOjixK0VmZDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DS7PR12MB5765.namprd12.prod.outlook.com (2603:10b6:8:74::19) by DS7PR12MB6237.namprd12.prod.outlook.com (2603:10b6:8:97::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6588.20; Tue, 11 Jul 2023 21:02:44 +0000 Received: from DS7PR12MB5765.namprd12.prod.outlook.com ([fe80::670e:64bd:78ea:b489]) by DS7PR12MB5765.namprd12.prod.outlook.com ([fe80::670e:64bd:78ea:b489%3]) with mapi id 15.20.6565.028; Tue, 11 Jul 2023 21:02:44 +0000 X-Gm-Message-State: ABy/qLYXnYWubFUQEvvoNsFbLGkEDupYaj+k/vR4a83KQXdpm4e57Os8 p37UG3VpAphWHBjTJD1gIGEe7246C+30h7S06C0= X-Google-Smtp-Source: APBJJlGXMtCmf0zoKVYooBeKizfwU4iVf9KRgCBBVsWhT/l7zj3ZJfFk+BvgyVcRoHKguZe/flfr03ERLVuyWoEb3OY= X-Received: by 2002:a5d:8258:0:b0:783:5452:e335 with SMTP id n24-20020a5d8258000000b007835452e335mr18692948ioo.6.1689109362618; Tue, 11 Jul 2023 14:02:42 -0700 (PDT) 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: From: Fangrui Song Date: Tue, 11 Jul 2023 14:02:31 -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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-TMN: [1GDpUXW/QqlqvnFBbaA+j++PQ+EJJ4qj] X-ClientProxiedBy: CH2PR16CA0011.namprd16.prod.outlook.com (2603:10b6:610:50::21) To DS7PR12MB5765.namprd12.prod.outlook.com (2603:10b6:8:74::19) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS7PR12MB5765:EE_|DS7PR12MB6237:EE_ X-MS-Office365-Filtering-Correlation-Id: 491945e8-0aeb-4d2c-299c-08db82522bc1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LQzTDticaB/R/MOKirjJxjsjlXp9ntjjD8ohKSx9vQjCIoH40jv2Bt55wXql2R21QhBVNJblJV+ITUaSWPKYUQwvaXw6dmMIqVLxunOBDled964VCEEMZsLNiJpQy4qw4f3eLNgCblXhbokPBw8pOnDCCW0whT/6njxupUtSbkHJ0Azmal2zXZfKr4aRGoqSeZDXyYq1CGKpwXrUFB/VCD/y+oduH5AR2qgRYTjc8V5IiSA+nGLIBVumFiVyVK/NIRS7pvUqWEyTZyuBL7ohKpgwUBuTg8ygJxpGiPgiHThCsBNGhTleg5PlVmu6gyZVcct5baHQ7h/P2nAHZVJbQNEVyySzylYTjhkWd8zRB/rO7Wqk22GHaEScBWTGt+bNF9wG2scJRHcFe8lLpo9Qnw+RLJBTmmP045iDUdBLd3+IqHnbBMCLmfGcIdG8NEdVtvMeBLPa9zTXJss/ACNYhjWmHUiSowpGNSNZ9tVn7EmYuD0LDNOtYJwLi473gd9uTab6JOB3cNSceTH4dAGqpUr7LxG0J5PsrfPHCLG/rT4= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WFlIbGNTOGJDZHFIVmxzdHMrWDJ3aWpvaFhmRG1DWFRwRGFTL0ZZOFMrLzNi?= =?utf-8?B?NUF1VkpaM3pjVFVLTmF4Y1VJSzU0MnhaSE5IUy9HNGtXWWtjRktWbzhGRk45?= =?utf-8?B?Uk5RYVJRNWFoSkNzdHFrbFBqMjNscEFRa2dRUndEbFdBbkFqdnEyR0RqU2FB?= =?utf-8?B?Y3NzRFpuc0t6UUdoQkRFOHRvQXBDQWZvQ1dvTkFrZE1HVmxtZ3FCVW1mbzFy?= =?utf-8?B?bUM0WkE3K2NBdi9oa2NjeU41WEM0YmNBTE01WGQrV0ZpNVZaOWlZbkZmL0Fm?= =?utf-8?B?NVlQeUswNXlrT2poVmROeDBvNndPOHl3N0t6TU1UTk5yZHE2TTB3T3Eyc0ll?= =?utf-8?B?MmJZT0pkZnBzcTluSlZsZ2dQVElxVGZPbHF2SE91ZmxqNVpXaEplUEk1enFq?= =?utf-8?B?N0JNN1o0MWFQZWVaa2Q1Ry8vK0FoSjAyRXFucVpvT1dlakUraG90SHZ3Q2lK?= =?utf-8?B?bXJQU0xmM1pTWXlGYnhDditlSkhlenlzNlhSYnMwR3lmWUFwa05jbE5RakRm?= =?utf-8?B?THl2MDZ1bDNSTmw5a2IwYTlQOUVINkx1MUtlRUxPUkR1WFZrT1ZXSVV5dENK?= =?utf-8?B?UnJRa2ExcHowckdEOTRkV1RuMmNzV1pSTkl1Nm82bEI2ZGR3V0VPS3dlaHZI?= =?utf-8?B?eCt2T0FEellkUndKWlFkVEc1cnlWNVNRTzY0Q3hUS3JRVjBRWUMyaUJHTjJW?= =?utf-8?B?ellFaWd2S2J6WStDUWpsazZJdDdaVkdpWjBIWlFRdHFiRE9FcWdvelVhWllZ?= =?utf-8?B?VVVEREV6SHk0SjdaNEYyOEpkdEVmYmgyZUlDa2VRWUw4K2NpRnlxWlV0VnhO?= =?utf-8?B?SWtiaUVQRkNkQjhiSXNERFZTQ1laS255U2xXM3lPNkNMTWJSYXVtNS95YmE0?= =?utf-8?B?b1FaOGd2biszUWVRSVdqWWJVMXFVZ3BjaTBHbGt2VGxoczZaL1g3RnQ0U2Vq?= =?utf-8?B?UkFraHRDc0NxS1RlR280MHc2QnY1SElVSmJsbGN1QjRLb1RYV3RBdXFEbUJ4?= =?utf-8?B?RDI3NkFmcm5la3NVemlhbGZlUENONCtCZm5DNFhkZzdhcGsyekU0WUpFeTVG?= =?utf-8?B?dE9JNlpRT3hqZGd2VzVpMmFNdjJoaEUyWkMrWStNNG1aaFU4TDB0TVA3ZE5q?= =?utf-8?B?em9WOFh6djRURk82NFFocmxQK0lWbzVQNDgxRCs4UDdabzhRUm5ROGdtRGV1?= =?utf-8?B?b3VWQlJrbk1uL2syZkRxNzdGVWxhVlc3OFUvYWQySEd0NjQwbDJ0Ukd2bXhW?= =?utf-8?B?b0dFUHNsVzFTMnVTRzR5cHpVRzd1TXZOMnozZzJpTnN3NDZJNE9oSnBIa1Jh?= =?utf-8?B?akZCQ2RHN0szUUhFdzBFMUdnc2hzRnQ2V1c0MGovMFg4b0dzVE5pZUxrSmJx?= =?utf-8?B?cXo5K3JpYWJ2MktDbC9zRlcyVlFWOVRxSWJmR1pCWE4rZWdaQnNXalZrNDBJ?= =?utf-8?B?cS9sVWxIUDdtaHdHd3BIR2w3WTFFanlScTBYZVBRTzhpNXZTdWRxdlNJVXAz?= =?utf-8?B?MUJLNDU2a2NPTnB6NVliazVTWEVuS2NMTHVudW1GRzN4YldWQVRUVTVwWSs5?= =?utf-8?Q?8+BNQcdWbxwbtTFwEK4/r3JKifYf3tBsQJf6sa2QJK6e2+?= X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-71ea3.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 491945e8-0aeb-4d2c-299c-08db82522bc1 X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB5765.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jul 2023 21:02:44.1317 (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: DS7PR12MB6237 X-Spam-Status: No, score=-2.7 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 Fri, Sep 16, 2022 at 2:53=E2=80=AFAM Nelson Chu wr= ote: > > 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|M= ASK_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_J= AL, 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_ITY= PE_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_A= ND, match_opcode, INSN_ALIAS }, > > >> {"and", 0, INSN_CLASS_C, "Cs,Ct,Cw", MATCH_C_AND, MASK_C_A= ND, 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 I apologize as I haven't read all prior discussions. For many instructions, the "i" form is written in the ISA manual and prevalent. 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. % 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. > > > % 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 mere= ly > > followed the GNU behavior? > > > > Jan