[PATCH v9 0/1] RISC-V: Support ".option [no]exact" assembler directives
Kito Cheng
kito.cheng@gmail.com
Wed Feb 11 06:26:14 GMT 2026
Reversed ping, it already pass the release period of 2.45, I assume
this is OK for trunk now? does anyone can commit that?
Thanks :)
Nelson Chu <nelson@rivosinc.com> 於 2025年7月12日週六 下午12:53寫道：
>
> LGTM if passing regressions of riscv-gnu-toolchain. I think this isn't urgent, but if people in the risc-v community want it in the 2.45 release, then I think it's better to merge before the 2.45 branch is created. We don't have much time for now, so hope won't cause trouble in a rush.
>
> Nelson
>
> On Sat, Jul 12, 2025 at 11:17 AM Tsukasa OI <research_trasio@irq.a4lg.com> wrote:
>>
>> PING!
>>
>> Nelson's refined C extension handling changes some instruction classes and
>> I rebased on it.
>>
>> And to Jan, I'm so sorry that I didn't notice some of your questions.
>> I hope that you accept the changes if it seems okay,
>> as Nelson asked you as in:
>> <https://sourceware.org/pipermail/binutils/2025-May/141144.html>.
>>
>>
>> On 2025/05/16 18:44, Jan Beulich wrote:
>> > 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.
>>
>> Thanks, that's right and I decided to treat them as regular aliases.
>>
>>
>> On 2025/05/16 18:44, Jan Beulich wrote:
>> > 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.)
>>
>> I assume that the user which is aware of the exact mode knows what they
>> want and I think using macro instructions means, the user have *less*
>> strict requirements of emitted instructions there (especially "li"; so,
>> I entirely allowed macro instructions inside the exact mode).
>>
>> Still, expanded instructions respect the exact mode and automatic
>> instruction compression does not occur if the exact mode is enabled. The
>> final effect is much like complying with the RISC-V Assembly Programmer's
>> Manual without auto compression.
>>
>> I omitted the tests since many would be redundant but if that's necessary
>> (whether the instruction sequence matches to the results as in the Assembly
>> Programmer's Manual), I'll add them / change some of the existing tests.
>>
>>
>> Best Regards,
>> Tsukasa
>>
>>
>>
>> Version 9 (2025-07-12) - THIS VERSION
>> ======================================
>>
>> * Effectively a ping (again).
>> * Reordered relaxation flags for better readability.
>> * Rebase against commits including Nelson's 34fcc16e79b4
>> ("RISC-V: Clarify the imply rule of c").
>>
>>
>> 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)
>> =======================
>> cf. <https://sourceware.org/pipermail/binutils/2025-May/141212.html>
>>
>> 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.
>>
>>
>> Version 7 (2025-05-17)
>> =======================
>> Placeholder of ChangeLog in the commit message is removed.
>>
>>
>> Version 8 (2025-05-29)
>> =======================
>>
>> * Effectively a ping.
>> * Rebase.
>> * A grammar fix (i.e. -> e.g.) on riscv.h.
>>
>>
>>
>>
>> Tsukasa OI (1):
>> RISC-V: Support ".option [no]exact" assembler directives
>>
>> gas/config/tc-riscv.c | 42 +++-
>> 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 | 188 +++++++++---------
>> 20 files changed, 789 insertions(+), 109 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: 8b0a598853163772f412c9b3df37e66f41960479
>> --
>> 2.43.0
>>
More information about the Binutils
mailing list