[PATCH 0/2] RISC-V: Make some instruction non-aliases to fix a disassembler issue

[Tsukasa OI <research_trasio@irq.a4lg.com>]

Hello,

Certain instructions are defined as aliases (with INSN_ALIAS) but some
of them have no "parent" instructions (without INSN_ALIAS).

As a result, if the disassembler has given an option of `no-aliases',
they will be printed as `.4byte', unrecognized instructions.
This patchset fixes thie issue.

Note that zip/unzip fix is based on my previous patchset:
<https://sourceware.org/pipermail/binutils/2022-June/121159.html>

Changes since the patchset above are:
-   Also fixed `fence.tso' instruction
-   Added testcases (technically, added `-M no-aliases' to existing
    tests to make sure that target instructions are not aliases)

Tracker on GitHub:
<https://github.com/a4lg/binutils-gdb/wiki/riscv_dis_nonalias>
Supersedes:
-   <https://sourceware.org/pipermail/binutils/2022-June/121159.html>
    (Tracker: <https://github.com/a4lg/binutils-gdb/wiki/riscv_dis_rv32_zip>)

    Sidenote:
    I started listing my Binutils submissions on my GitHub Wiki:
    <https://github.com/a4lg/binutils-gdb/wiki/Patch-Queue>
    hoping that current status and conflicting patches are clear.



1. zip/unzip (RV32_Zbkb) [PATCH 1]

`zip' and `unzip' are instructions from Zbkb extension (RV32 only).
They are, in fact, specialized forms of `shfli' and `unshfli'
instructions, respectively.  The problem now is, since generalized
`shfli' and `unshfli' are not ratified AND `zip'/`unzip' are defined as
aliases (with INSN_ALIAS), it causes a problem on the diassembler.

With following assembler file with `-march=rv32i_zbkb',
    _start:
        zip a0, a1
        unzip a2, a3

The output with `objdump -d' is like this:
    80000028 <_start>:
    80000028:   08f59513      zip     a0,a1
    8000002c:   08f6d613      unzip   a2,a3

However, output with `objdump -d -M no-aliases' looks like this:
    80000028 <_start>:
    80000028:   08f59513      .4byte  0x8f59513
    8000002c:   08f6d613      .4byte  0x8f6d613

You can see that `-M no-aliases' option causes disassembler to ignore
`zip'/`unzip' instructions but cannot find right non-alias instructions.

Until generalized `shfli' and `unshfli' instructions are ratified,
my simple patch (which makes `zip'/`unzip' non-aliases) does the trick.

Once generalized `shfli' and `unshfli' instructions are ratified, the
status will be a bit different.  As the same issue is already present on
disassembling `zext.h' instruction on RV{32,64}_Zbb_Zbkb, this is to be
fixed with a different patchset:
<https://sourceware.org/pipermail/binutils/2022-June/121159.html>



2. fence.tso (RVI) [PATCH 2]

`fence.tso' is a subset of generalized `FENCE' instruction in the RISC-V
ISA.  However, this is not the case on GNU Binutils.

Since we don't have proper way how to describe fm (fence mode) field in
an assembler mnemonic of the `FENCE' instruction, GNU Binutils' `fence'
instruction is defined as RISC-V `FENCE' instruction where fm=0b0000
(regular fence).

As a result, `fence.tso' (which has fm=0b1000) is not a subset of GNU
Binutils' `fence' (which has 0b0000).  So, `fence.tso' must not be
defined as an alias (with INSN_ALIAS).




Tsukasa OI (2):
  RISC-V: Make `zip'/`unzip' on Zbkb non-aliases
  RISC-V: Make `fence.tso' a non-alias

 gas/testsuite/gas/riscv/fence-tso.d | 2 +-
 gas/testsuite/gas/riscv/zbkb-32.d   | 2 +-
 opcodes/riscv-opc.c                 | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)


base-commit: d2acd4b0c5bab349aaa152d60268bc144634a844
-- 
2.34.1