[PATCH v6 0/1] RISC-V: Support ".option [no]exact" assembler directives
Tsukasa OI
research_trasio@irq.a4lg.com
Sat May 17 04:35:10 GMT 2025
On 2025/05/16 18:44, Jan Beulich wrote:
> On 16.05.2025 11:25, Tsukasa OI wrote:
>> On 2025/05/16 18:12, Jan Beulich wrote:
>>> On 16.05.2025 11:00, Tsukasa OI wrote:
>>>> On 2025/05/16 15:38, Jan Beulich wrote:
>>>>> Looks quite okay to me. I'm not entirely certain we need the new insn flag, but
>>>>> perhaps it's good to do it this way to also cover the doc aspect (i.e. making
>>>>> explicit which aliases are which).
>>>>
>>>> Thanks.
>>>>
>>>> The intent of the new instruction flag is, we don't want to disable all
>>>> aliases but only aliases which will have unintended side effects in the
>>>> context of the exact mode (currently, this flag is applied to RVC
>>>> aliases which will change the instruction length from the non-RVC _main_
>>>> encoding).
>>>>
>>>> For instance, we want to disable aliases of "addi" / "add" (that turn
>>>> into compressed instructions like "c.addi") in the exact mode but we
>>>> _don't_ want to disable "sgt" (set if greater than) aliases because
>>>> "sgt" only turns into "sle" (set if less than or equal; with two source
>>>> operands flipped) and unintended side effects in the context of the
>>>> exact mode will not occur.
>>>>
>>>> For documentation, let me consider. I think the best place to
>>>> improve/describe is at the definition of INSN_NON_EXACT, right?
>>>
>>> I'm sorry if I caused confusion - I didn't mean to ask for anything to be
>>> added.
>>
>> Ah, looking now, I think the description of INSN_NON_EXACT is too brief
>> to decide when to use and I want to add (at least) DOs and DON'Ts.
>>
>> And, I found a clear bug and a border case while reviewing my patch set.
>> So, I thought it's a good time to reconsider.
>>
>> 1. "unimp" (compressed alias) lacks INSN_NON_EXACT and must be added.
>> 2. Decide whether we add INSN_NON_EXACT to non-compressed
>> aliases of "zext.[wh]" (likely to keep as-is).
>
> zext.h only has a C alias, which needs treating like other compressed aliases.
> Same for the C alias for zext.w; the Zba alias likely also needs treating
> like that, but then there's only the macro one left. Which reminds me that I
> wanted to ask about macro insns: Should they actually be permitted in "exact"
> mode? (This _may_ be okay if what the macro expands to is precisely what the
> spec says, but I'm unsure whether there weren't a few "extensions" in our
> code.)
>
> Jan
>
Thanks.
For "zext.[hw]", you're completely right and I'm not sure what I was
thinking at that time. Anyway, PATCH v6 is submitted (Zba/Zbb/Zbkb
aliases of "zext.[hw]" did not set the INSN_NON_EXACT flag) with changes
as in the section below (note: you reviewed PATCH (v4), not PATCH v5).
"Unintended side effects in the context of the exact mode" as mentioned
in my mails are roughly defined as follows:
(1) Automatic instruction compression
(compared to more canonical one with the same instruction name) or
(2) [Currently not controlled by INSN_NON_EXACT]
Other relaxation possibilities other than instruction expansion
inside the macro (but instructions emitted by macros are still
subject to (1) and (2)):
(a) Branch relaxation implemented in the assembler
(b) Linker relaxation enabled by the assembler and performed
by the linker
And... I found that I made a blunder in PATCH v1-v5 (forgot to test
whether the macro works when the exact mode is enabled) and PATCH v6
contains the fix to this.
Thanks,
Tsukasa
Version 1 (2025-05-13)
=======================
cf. <https://sourceware.org/pipermail/binutils/2025-May/141042.html>
This is the initial proposal.
Version 2 (2025-05-14)
=======================
cf. <https://sourceware.org/pipermail/binutils/2025-May/141075.html>
No changes in the code.
* PATCH 1/2 (Commit message):
Clarify again that, in the scope of this fix, the relocation is
optionally removed when the linker relaxation is disabled.
* PATCH 2/2 (Commit message):
Notify that the exact mode is already implemented in LLVM.
* PATCH 2/2 (Documentation):
* Imply that there is a small room for minor specification
change related to ".option exact/noexact".
* Document that there are flaky interactions between
".option relax/norelax" and ".option exact/noexact"
and add a warning about them.
Version 3 (2025-05-14) - PATCH 1/2 committed with small changes
================================================================
cf. <https://sourceware.org/pipermail/binutils/2025-May/141092.html>
No changes in the main code (but minor change in the test code).
* PATCH 2/2 (Commit message):
Clarify that interactions between ".option relax/norelax" and
".option exact/noexact" are flaky (documented in PATCH v2 but also
noted in the commit message).
* PATCH 2/2 (Test code):
exact.s: Add comment "# noexact by default.",
clarifying that the exact mode is disabled by default.
Version 4 (2025-05-16)
=======================
cf. <https://sourceware.org/pipermail/binutils/2025-May/141139.html>
Adjustments are made after Nelson's changes to error messages and
the support for Zilsd/Zclsd extensions.
* Commit Message
Small clarification/fix about handling of macros.
* Code
Support Zilsd/Zclsd extensions.
* Test Code
Simpler error messages as Nelson changed.
Version 5 (2025-05-16)
=======================
cf. <https://sourceware.org/pipermail/binutils/2025-May/141201.html>
A bugfix on "unimp" and clarification.
* Code
Fix to "unimp" (compressed alias).
* Comment
Clarification to INSN_NON_EXACT.
Version 6 (2025-05-17) - THIS VERSION
======================================
A bugfix to allow macros in the exact mode and more clarification plus
test cases.
* Code
BUG FIX: allow macros if the exact mode is enabled.
I completely forgot to compare pinfo with INSN_MACRO and now fixed.
* Commit Message
Even in the macros, it is clarified that instructions emitted by
macros are still subject to the exact mode behavior if enabled.
* Test Code
New test cases (and small modification to li{32,64}.s) to test that:
(1) Macros ("li" here) in the exact mode works as expected and
(2) Automatic compression in the macro expansion is still suppressed
li{32,64}.d: compression instructions are generated.
exact-li{32,64}.d: only non-RVC instructions are generated.
Tsukasa OI (1):
RISC-V: Support ".option [no]exact" assembler directives
gas/config/tc-riscv.c | 40 +++-
gas/doc/c-riscv.texi | 13 ++
.../gas/riscv/exact-branch-extern-exact.d | 32 ++++
.../gas/riscv/exact-branch-extern-noexact.d | 50 +++++
gas/testsuite/gas/riscv/exact-branch-extern.s | 40 ++++
.../gas/riscv/exact-branch-local-exact-fail.d | 3 +
.../gas/riscv/exact-branch-local-exact-fail.l | 43 +++++
.../gas/riscv/exact-branch-local-exact-ok.d | 75 ++++++++
.../gas/riscv/exact-branch-local-noexact.d | 149 +++++++++++++++
gas/testsuite/gas/riscv/exact-branch-local.s | 138 ++++++++++++++
gas/testsuite/gas/riscv/exact-li32.d | 18 ++
gas/testsuite/gas/riscv/exact-li64.d | 45 +++++
gas/testsuite/gas/riscv/exact.d | 15 ++
gas/testsuite/gas/riscv/exact.s | 11 ++
gas/testsuite/gas/riscv/li32.s | 3 +
gas/testsuite/gas/riscv/li64.s | 3 +
.../gas/riscv/no-relax-branch-offset-fail.l | 5 +-
.../gas/riscv/no-relax-branch-offset-fail.s | 11 +-
include/opcode/riscv.h | 14 ++
opcodes/riscv-opc.c | 180 +++++++++---------
20 files changed, 784 insertions(+), 104 deletions(-)
create mode 100644 gas/testsuite/gas/riscv/exact-branch-extern-exact.d
create mode 100644 gas/testsuite/gas/riscv/exact-branch-extern-noexact.d
create mode 100644 gas/testsuite/gas/riscv/exact-branch-extern.s
create mode 100644 gas/testsuite/gas/riscv/exact-branch-local-exact-fail.d
create mode 100644 gas/testsuite/gas/riscv/exact-branch-local-exact-fail.l
create mode 100644 gas/testsuite/gas/riscv/exact-branch-local-exact-ok.d
create mode 100644 gas/testsuite/gas/riscv/exact-branch-local-noexact.d
create mode 100644 gas/testsuite/gas/riscv/exact-branch-local.s
create mode 100644 gas/testsuite/gas/riscv/exact-li32.d
create mode 100644 gas/testsuite/gas/riscv/exact-li64.d
create mode 100644 gas/testsuite/gas/riscv/exact.d
create mode 100644 gas/testsuite/gas/riscv/exact.s
base-commit: ae68929a8dfda10a993375f4ab93fcb89c6042d8
--
2.43.0
More information about the Binutils
mailing list