public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Stefan O'Rear <sorear@fastmail.com>, Fangrui Song <i@maskray.me>
Cc: Binutils <binutils@sourceware.org>,
	Nelson Chu <nelson@rivosinc.com>,
	Jessica Clarke <jrtc27@jrtc27.com>,
	"kito.cheng@sifive.com" <kito.cheng@sifive.com>
Subject: Re: [PATCH 1/3] RISC-V: re-arrange opcode table for consistent alias handling
Date: Mon, 17 Jul 2023 08:50:00 +0200	[thread overview]
Message-ID: <09d96f5d-a547-6c3b-f0f2-b40484fa5a9f@suse.com> (raw)
In-Reply-To: <8c44aaa6-7dac-4b1b-9558-33d15ed9b9f8@app.fastmail.com>

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 <jbeulich@suse.com> 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 [1] 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

  reply	other threads:[~2023-07-17  6:50 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 [this message]
2023-07-21 22:16                   ` Song Fangrui
2023-07-22 15:14                     ` Jeff Law
2023-07-22 16:55                       ` Andrew Waterman
     [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

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=09d96f5d-a547-6c3b-f0f2-b40484fa5a9f@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=i@maskray.me \
    --cc=jrtc27@jrtc27.com \
    --cc=kito.cheng@sifive.com \
    --cc=nelson@rivosinc.com \
    --cc=sorear@fastmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).