From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2077.outbound.protection.outlook.com [40.107.22.77]) by sourceware.org (Postfix) with ESMTPS id A4E8A3858D20 for ; Wed, 12 Jul 2023 08:15:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A4E8A3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l3sN9NhfaIRSg/5kBZWJhPN92NS8q6B7OddPpcDHHvAUFaLZB1XodDST/XWttTaQw/Qj/jTbitRO8CxnlpqNdHnK0JnLp3dchAqXxzNjSkilC+9w/5kMwJZUDA+et9np6fH8Ht4urDPjXeDdYlAOp3ba+v6nDRGGraV46VP7bzpM4ca5B22PXieLdejmMRYxOcn+DP7tf3glLXW/vvxmbFj2Ml2zLW2lPEIoMFnOa0zMr6Zo72L2pVw81uwGwRRSneds4dZa2R71YDMmdO6xH0ejs15bUHDSTz7QxF8NMjpKHedsLh6gC1ZYc9cWaQRigTUPNWAY4ZihThFyZM61ag== 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=AB0cPao1enshed4MWRjoYJmKZC2PTHp+HTujokv8zvU=; b=NVGa/k7cOiiHspbO8vmKk/ESjAHyzzduO0G2QTgZb6PpCl8fF39U/SrT489ZBOQnfl6RVHBjDS/Iel2A9ancq36OkkpyM6obJH7IN5ZWbEffcHyNJJ2XxG9ZXEOfamsmKPn+gfAZnBIbh7Ort7y4N1b+ybF2CoXtyLENPIcDAj32VV0XzWXn0AOdxdc8hcJIeDKy/OxqOpFgLDIs8pJrbQBTn4hBGG5F/dToHZn56fNeEx4QRyYoIVsbI2guQX6FAyejC3fOIEUp3/bfoyYcui3CHlnyHw8vdnvEooodvrgkxk+paFPQAatQstGUbLkAqPeJI95cjY9Naqe8Y0mw3A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AB0cPao1enshed4MWRjoYJmKZC2PTHp+HTujokv8zvU=; b=nIhFj4ZhNBUvR5JkJTxSxJZ/DP2r1a9dxj5p2d3mmq5DIrxvIXPckeQV8UbbCPWQywrO79/CNoA7Xd25a3VxH28MHGznTDv9qI/vjlJePHjWIn8JtVXfwn+klV41ebET3VRpfQDQCK7DaVb0PhXyoW5KH6ymca6qjd/9uNvGtl6RtYDEH0lG7DpdUqeRn5SUG0N6stylvWvzMcX573N7XBwl6fp4EmXxmnlWlgPUSuwpMnaSYw26Ocxqm+afnSw60ncavGI2YCWrhwAstxXVuTNVPp6AkMf0+JivxoDw1gnGOQw6mUg6HcE4Mjji92/SKnWOKSL+mHcpwGuvYxtS4Q== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com; Received: from AS8PR04MB8788.eurprd04.prod.outlook.com (2603:10a6:20b:42f::21) by VI1PR04MB9884.eurprd04.prod.outlook.com (2603:10a6:800:1d0::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6565.31; Wed, 12 Jul 2023 08:15:09 +0000 Received: from AS8PR04MB8788.eurprd04.prod.outlook.com ([fe80::cbc0:69aa:c9a2:198e]) by AS8PR04MB8788.eurprd04.prod.outlook.com ([fe80::cbc0:69aa:c9a2:198e%7]) with mapi id 15.20.6565.016; Wed, 12 Jul 2023 08:15:09 +0000 Message-ID: <18227b09-0d51-3e24-b782-5cf74e41e494@suse.com> Date: Wed, 12 Jul 2023 10:15:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH 1/3] RISC-V: re-arrange opcode table for consistent alias handling Content-Language: en-US To: Fangrui Song Cc: Binutils , Nelson Chu References: <7cb92a0b-d1ef-e3db-4773-0b6cd5183272@suse.com> <40281e59-659c-044f-0c86-1db77fd17b5c@suse.com> <09666d48-99f0-ae25-ef84-f542da3628ce@suse.com> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR3P281CA0106.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a3::16) To AS8PR04MB8788.eurprd04.prod.outlook.com (2603:10a6:20b:42f::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR04MB8788:EE_|VI1PR04MB9884:EE_ X-MS-Office365-Filtering-Correlation-Id: 3a81d36c-ff33-40ca-5b0d-08db82b01ba0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ewdpf/sdrxUVmLZDKvDQE/eW8lUZhh+aqWE8q7bOxZcAS28a7vF5wTHkE4NAenYH24sFOig218z7hvfi3Dhh4Id7NprdkQsVsz1z0i60Ak/4yEiTBpeQ278TrInhYLIDCgINDJREss4yOJ2fPrpbogS/rIeFjNJNy7qPM3PRMn340ID4QSKpjf2ZCAuycuhy0wefTiF8grP0MA5f0Or27py2CLYmNDDQd80YGZA2yue5HPXM63fdK13jyYaLilG8+qhd7xgHNjX2UV/2RYMQVBqiJIHl0lBJPyqyYJFadYfLM5lkooItLleLF6Gxwt3/Xx4aYDHdnY6dJJ5ckUa8xskKQaMiNAhknKJ2YJ99WqYl5/0FfVXPfYWYSTp6nj0pBOsxQLxLJMLph2vqbg7ntZPpdR34+Zlg0JtrHm4hgvGvnAz5XDhU2YfuSI0seibJYJRre9eOsNrxLq6T1UCONVrUXsR8X3YcJHD1BtSTguJlmCdF7jRdjAKHCFW/9GNpT4MIkfuFANL3HngbHqk369M5vjiUle8TGpiKgDgoB18+oOJW8PG1z6hYmcHZcNB7rzkCHkM2qqoVsvNJWKVNR0L84HO34Uv9tE5BEQvZ8xAdBoPskWxfub2XffO4AjaYY1UJSIs3M97SEVcziks+nABzFFE46l7v1sWfykw0NR0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS8PR04MB8788.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(366004)(346002)(136003)(396003)(376002)(39860400002)(451199021)(83380400001)(86362001)(186003)(54906003)(478600001)(316002)(31696002)(41300700001)(4326008)(6916009)(66556008)(66476007)(66946007)(26005)(53546011)(6506007)(6512007)(38100700002)(6486002)(6666004)(36756003)(2906002)(5660300002)(8936002)(8676002)(2616005)(31686004)(781001)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dWNLbVVJNDFhUjJ3UitPSTYxSnNpUWpQR00wUUhpYnN5dlZTNStsc0M1M2F2?= =?utf-8?B?NGdZaXBnUDJwdVZ5cDFycG5MMzNnd0pSazZWWG5zcThqNFd0dVU0NVI4V0Vv?= =?utf-8?B?TEQrc2pMMnlwM3p0T0NjUUwxNGErVi9IMzFFalFjMXlpU2xmVTNIY0tueWtu?= =?utf-8?B?dmpxOUY2TUlHOFJ4YVpxL052YmF4SlVKQ1RUaVpzanNoRktFbVg1c2MrSEVU?= =?utf-8?B?VGNVb2hJZTVLOUlxaXlHeS8zNG1qL0hmd3c3cXlrU2c5SEc5Z3VlYnZwcGto?= =?utf-8?B?TkJaczl2Y1ZKeml3dDlIVG5XSUVNSzRPZFZqU1J6ZW1SSHJQQzBENGF0cGNp?= =?utf-8?B?M0h3N0RhQVZ5aCsvSTIvOFh3MXBzSkovbzZUMzZOZWpUS0hWU1VIanNNUHMw?= =?utf-8?B?Wk1xaURvenFSUTl4ak9lTS9yaVVYMiszZVhuQ0JoN0JBOTk1MkFOT0hacHRz?= =?utf-8?B?cUUwY3NhQ05HUTl3WndnNEhXMy9xeHMxNGFYQ3IxbnB4czNsWEdmQjVtYkow?= =?utf-8?B?cHV2cDlvcWI2N0g1eWxJSEFUalk0RGRpaHlTalNyVVBSQ2lodWlTMjhhNTJE?= =?utf-8?B?RUlCZEdsNjd6YXlja0tGbXlWbngrVjJ2ZjBDVGNsWkMxWGM4UzhGUk9pL3Zt?= =?utf-8?B?UTFQTENLazc2VU5nY2I1Vmh5V3F1M3N2ZnJyalU4TjBneDFFaUxwNHNua2Zq?= =?utf-8?B?ZzVEQlZEVTJHNkhDRFA5QUhmb0pybGVSOW85Z2JKeHhQaWFHNGpkWldPMTdq?= =?utf-8?B?aks2NTMrYVdUZHhJTWxObmJEaUV3cUNzMWJuWXdseW9yWUxlem9iNnFuU3dE?= =?utf-8?B?Z0FsemliUjZha2t1bXVFUE1SU04xZkdjNUtZaU10TUJTRE9FaVVRYUQ2R0hR?= =?utf-8?B?b2NhSU1TeEdmU1c1WVpkV1pyNjFyOTN1Y2UzeUFycGpHZ3RjdXV5UDVrbTEx?= =?utf-8?B?aUk4L1NoaXRXU2c1bktVNWd5UCs5VWd0Wmk4N1Blc09SUXF2RDBtVHJvN0pY?= =?utf-8?B?ZFpvWFRUM2hGbjRpL1I4U2QvUlVCZE9oR3EyNlpIaUJ6dnYrOVVLaG8wWTVR?= =?utf-8?B?Wk81M09KU0hybGlVcENZNlFTQ3ozQzI2cWIvN2hLQis3bTFxMTBOaE9OWVB4?= =?utf-8?B?bzgrV3hGOEZHOXY5dmJTcFdPeVZyckNuSHhaNnhRdUpYUTNlelhEbnFZMzc2?= =?utf-8?B?SlNuRkVURWp3NmRYTHZkOC8yMmN4bzBaR0xsYktIbksrTFdUN05yT2xrV1lK?= =?utf-8?B?YmxIUys5ZDBWQVJVYVN3TEJQZW1WNXBlc2pqYzZQdmEyV0VkRkRFWml4QlFp?= =?utf-8?B?U2Z1eEdBcHVYaGxnVUttbjVlWW1pRm8wNnpKbVhhVGZBeDN3ZStsWHhWYTli?= =?utf-8?B?TFdIdXVwWFA0eEYyUTRjdDU1Wi9jOHYydnAwTUhvejBUV1NoYzh6U2RTOGpG?= =?utf-8?B?K3AxR0ZiRERvekFkUThPanVwcUJiNUwwVXk2UW95S0t5T1ZJR3pSdHVwY2Q2?= =?utf-8?B?MitZemh2eHRERW5wMXBmZklTZ1REdHN0ZTRLQkU1UWhyc1h0a2dwSGJ0QWRV?= =?utf-8?B?T3hJdXZFZ3lzNjRKZ0s1cU8rcEJiU2FpdXh4aml1YnFoeXZNR3Y0K2VCanpV?= =?utf-8?B?akI5N2s0WDdqZ2VlWnAwRE4rVE5mZm5sL3plMUppdTVJa3hFNWFyVXNoa1A3?= =?utf-8?B?RG1tajQzWGZ0cjVBVlFBNC84c28weVIwQmQ5Vm1qU0ZjbUNPRUUyS1B1aVla?= =?utf-8?B?bHV3TzhtU0NrdE1VSU50OTNzSVE1WVpoR0ltaWY1SEpsMGFTQVh0TlgyNG9z?= =?utf-8?B?NCtYNkorTjVUSjVidWU1d2FMYXprdDJFak1uYjdxdytrTzViTDR4bmR1VWU4?= =?utf-8?B?N3FmRlBLMGo3ZzUwRm1GSW1lN093ckF4ZlRvS25TUjl4REFiTnB5Rkh2N2k4?= =?utf-8?B?THRvUHhKVXhEazd4cFJNYnVnbEJraU04N1NDS1NuTGUva256YUNxUEYybWkv?= =?utf-8?B?VDFRNlZsamVRZzQxMDQ0NmFzZzJnWnk5eHM3QjZCOHhHc2ZldkxBbGNLZk11?= =?utf-8?B?SThOVWh0S3I1RWxBSkkxVUM1bnNYeHIrOFBYR00rdkd6UnE4N2didWc1OHhm?= =?utf-8?Q?s6+G/FIRht2rFNdmQJRu1pdYq?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a81d36c-ff33-40ca-5b0d-08db82b01ba0 X-MS-Exchange-CrossTenant-AuthSource: AS8PR04MB8788.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2023 08:15:09.3509 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: TSnT+hxA+oyrpataHAvEtz2eKb47y97syURvGU7G5YyRT0HNoWCkH5ek9PXDuj7nu0IZX+seKYpVEVoaJLRljA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB9884 X-Spam-Status: No, score=-3027.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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 11.07.2023 23:02, Fangrui Song wrote: > On Fri, Sep 16, 2022 at 2:53 AM 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 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 > > 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 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. 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 > % 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 = 0" so llvm-objdump -d will never show > them.