From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) by sourceware.org (Postfix) with ESMTPS id 41E793858D1E for ; Sat, 22 Jul 2023 16:55:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 41E793858D1E Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-io1-xd2a.google.com with SMTP id ca18e2360f4ac-77ac14ff51bso126421639f.3 for ; Sat, 22 Jul 2023 09:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1690044947; x=1690649747; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=bwUtLDMTdbVOWNs4m1ixQ3MnvJc2mq5FXTnq5CCWTIs=; b=fnsuDv6OmxmzulDUheEGBjePHkzZ5Eah7rMnbDDbGwgK5iUFM7ggYNJsHqmVa1YnqU Gh5DabI40868v6TbFPcx2HlI2wLc5Dme9Yv6HHsZA6dBLte99YdFDTyaDXAURck2KQzj USOXSctB2RT8/uSP22taq9o73RWcQONuX3U+yv8waVFj8Xvvz+oZ1KHXbmDelrsFb5yO GNYv7OjMwNhQu/DESqb39cK5i0pjvkb6F9q8XJEsH1MjLmvh/Q7f63ykrn0gPChAhzqa wb5WbGDUL5jCAnTfNxXZuJVhNX767RcITy2W69DSR3C+doD0j4xlQ6JY1Ah8fJCNLTOC PC0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690044947; x=1690649747; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bwUtLDMTdbVOWNs4m1ixQ3MnvJc2mq5FXTnq5CCWTIs=; b=iav8cz6oL+FrXAGHANM394MhnnDO67FTm8Sxz1eUI+4Yp5ICGClMHGzT8DcWHjy1uv 2rgiPyvqgBs9yc8vQt7p5cS0g6F+eIImg3NL4oiVWxQHNm5xjPu19lHMkrHX5uM10CAk XC00vh/5OaT8yZZUM6SyOBctVDRiZmla6atmMOzKUoYlnCIiE/nwZyEpYc8K/XR1IyCp j4+d+EOcJMOCjouNRur31w51122RA0EuknFHrUYmisved7OA1mqAngvduC2nxW+a9t0W OvXHs0pqKb9fjpwVvoaknaw/7VqAujNI9yqv3l5GzZ7WzHnlI1TX0UDecMebAtAy7N37 jp5Q== X-Gm-Message-State: ABy/qLan/4SOpUxpCDyMIRS3eQpGU04182xCLmiC1zs99+4mXfRsCnw+ Q39p65CHjYCkWZuFqts9txgv5dTP1XTJ4+7R+4OzZcK5W7Hdwt83yBtdmfOw4GBhdoHXwya3UF+ G63zN4oUKxT7rfbdqtXBmpK1CyVoZuaYZEe36I+Ivbv1JwURC9131nZPI2uthyD8K+l3w5Hw5jQ == X-Google-Smtp-Source: APBJJlHPCONuoRr9Lw1YfnHMoNSWbOT4im9VFyQwb/1VgVQlLyxPir6hkrRN+mkcXuf7mVjtCvvYOg== X-Received: by 2002:a05:6e02:1041:b0:345:e5ab:e177 with SMTP id p1-20020a056e02104100b00345e5abe177mr2295569ilj.9.1690044946994; Sat, 22 Jul 2023 09:55:46 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com. [209.85.166.50]) by smtp.gmail.com with ESMTPSA id l13-20020a92280d000000b00345cdb39ba4sm1782637ilf.84.2023.07.22.09.55.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Jul 2023 09:55:45 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id ca18e2360f4ac-7835e5fa459so126850739f.2 for ; Sat, 22 Jul 2023 09:55:45 -0700 (PDT) X-Received: by 2002:a05:6e02:20c2:b0:346:2ad9:fe77 with SMTP id 2-20020a056e0220c200b003462ad9fe77mr3197632ilq.23.1690044944876; Sat, 22 Jul 2023 09:55:44 -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> <18227b09-0d51-3e24-b782-5cf74e41e494@suse.com> <8c44aaa6-7dac-4b1b-9558-33d15ed9b9f8@app.fastmail.com> <09d96f5d-a547-6c3b-f0f2-b40484fa5a9f@suse.com> <9b8011b2-2f15-96ea-9891-cc385cfcc9c9@gmail.com> In-Reply-To: <9b8011b2-2f15-96ea-9891-cc385cfcc9c9@gmail.com> From: Andrew Waterman Date: Sat, 22 Jul 2023 09:55:33 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] RISC-V: re-arrange opcode table for consistent alias handling To: Jeff Law Cc: Song Fangrui , Jan Beulich , Nelson Chu , "Stefan O'Rear" , Binutils , Jessica Clarke , "kito.cheng@sifive.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: Just as a reminder, the official aliases are not engraved on stone tablets. I suspect that, as we go through this exercise, we'll find cases where we really should retain the aliases, in which case we should just update the official document. Aside from that comment, this all sounds fine to me (provided, of course, the assembler will continue to accept these aliases in perpetuity). On Sat, Jul 22, 2023 at 8:15=E2=80=AFAM Jeff Law via Binutils wrote: > > > > On 7/21/23 16:16, Song Fangrui wrote: > > On Sun, Jul 16, 2023 at 11:50=E2=80=AFPM Jan Beulich wrote: > >> > >> On 15.07.2023 00:08, Stefan O'Rear wrote: > >>> 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: > >>>>>> I apologize as I haven't read all prior discussions. For many > >>>>>> instructions, the "i" form is written in the ISA manual and preval= ent. > >>>>> > >>>>> Why "prevalent"? The "i"-less forms are mentioned there as well, ar= en'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. > >> > >> That's a matter of taste, I'm inclined to say. But see below. > >> > >>>> We should not endorse the use cases by making objdump -d "prefer" th= is 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 thread. > >>>> > >>>>>> I wonder whether we can give these add/and/xor/etc without "i" low= er > >>>>>> 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 disas= sembly. > >>> The other aliases, which gas supports for compatibility with old vers= ions of > >>> itself but which were never part of any spec, are not preferred. > >> > >> This would be a fair policy, as long as there's a not overly troubleso= me > >> way of getting further entries on that list (whenever obvious instance= s > >> turn up). My main goal, after all, is consistency. What exact policy > >> underlies this is secondary to me. > >> > >> Jan > > > > Jan and Nelson, If this is agreed that we should use "addi" instead of > > the gas alias "add" in situations like addi x0, x0, 1, can either of > > you make a change to restore the old behavior? Thanks! > Given the ISA docs use "addi", we should follow that. While GAS does > provide aliases which allow things like "add" with an immediate operand, > those are non-standard and should not be preferred. > > In an ideal world the output of objdump should be compatible with what > GAS accepts as well as what the LLVM toolchain accepts -- while we may > not be there, there's no good reason to introduce additional > inconsistencies across the tools. > > So as Stefan noted, there are a set of aliases defined by the RISC-V > assembly reference. Those are the only ones that should be preferred. > > > https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm= .md > > > jeff >