From: Andrew Waterman <firstname.lastname@example.org>
To: Jeff Law <email@example.com>
Cc: Song Fangrui <firstname.lastname@example.org>, Jan Beulich <email@example.com>,
Nelson Chu <firstname.lastname@example.org>,
"Stefan O'Rear" <email@example.com>,
Jessica Clarke <firstname.lastname@example.org>,
Subject: Re: [PATCH 1/3] RISC-V: re-arrange opcode table for consistent alias handling
Date: Sat, 22 Jul 2023 09:55:33 -0700 [thread overview]
Message-ID: <CA++6G0Brv-W9tTC_m=e_fVzWBGCZcSLXsFoyNXpC8jtzAXOsCg@mail.gmail.com> (raw)
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
On Sat, Jul 22, 2023 at 8:15 AM Jeff Law via Binutils
> On 7/21/23 16:16, Song Fangrui wrote:
> > On Sun, Jul 16, 2023 at 11:50 PM Jan Beulich <email@example.com> 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 AM Jan Beulich <firstname.lastname@example.org> 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 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.
> >> 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" 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 thread.
> >>>>>> 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.
> >>> The aliases that are documented in  are preferred for use in disassembly.
> >>> The other aliases, which gas supports for compatibility with old versions 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 troublesome
> >> way of getting further entries on that list (whenever obvious instances
> >> 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
next prev parent reply other threads:[~2023-07-22 16:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-13 12:59 [PATCH 0/3] RISC-V: alias insn adjustments Jan Beulich
2022-09-13 13:02 ` [PATCH 1/3] RISC-V: re-arrange opcode table for consistent alias handling Jan Beulich
2022-09-15 2:30 ` Nelson Chu
2022-09-15 7:42 ` Jan Beulich
2022-09-16 9:53 ` Nelson Chu
2023-07-11 21:02 ` Fangrui Song
[not found] ` <DS7PR12MB576580071090C394AECFC618CB31A@DS7PR12MB5765.namprd12.prod.outlook.com>
2023-07-12 8:15 ` Jan Beulich
2023-07-14 21:25 ` Fangrui Song
[not found] ` <MN0PR12MB57613B59178FAADE5FCD3837CB34A@MN0PR12MB5761.namprd12.prod.outlook.com>
2023-07-14 22:08 ` Stefan O'Rear
2023-07-17 6:50 ` Jan Beulich
2023-07-21 22:16 ` Song Fangrui
2023-07-22 15:14 ` Jeff Law
2023-07-22 16:55 ` Andrew Waterman [this message]
[not found] ` <DS7PR12MB57658EF28577B41BF35C5E7CCB3FA@DS7PR12MB5765.namprd12.prod.outlook.com>
2023-07-24 7:23 ` Jan Beulich
2023-08-30 3:14 ` Fangrui Song
2022-09-13 13:03 ` [PATCH 2/3] RISC-V: drop stray INSN_ALIAS flags Jan Beulich
2022-09-15 2:43 ` Nelson Chu
2022-09-13 13:04 ` [PATCH 3/3] RISC-V: add alias for SLLI.UW Jan Beulich
2022-09-13 14:54 ` [PATCH 0/3] RISC-V: alias insn adjustments Tsukasa OI
2022-09-13 16:11 ` Jan Beulich
2022-09-13 16:58 ` Tsukasa OI
2022-09-14 6:26 ` Jan Beulich
2022-09-30 9:41 ` [PATCH] RISC-V: fix build after "Add support for arbitrary immediate encoding formats" Jan Beulich
2022-09-30 10:26 ` Christoph Müllner
2022-09-30 22:17 ` Palmer Dabbelt
2022-09-30 9:42 ` [PATCH] RISC-V: fallout from "re-arrange opcode table for consistent alias handling" Jan Beulich
2022-09-30 9:42 ` [PATCH] RISC-V: don't cast expressions' X_add_number to long in diagnostics Jan Beulich
2022-09-30 10:13 ` Christoph Müllner
2022-09-30 14:43 ` Nelson Chu
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).