public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Tsukasa OI <research_trasio@irq.a4lg.com>
To: Tsukasa OI <research_trasio@irq.a4lg.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Andrew Waterman <andrew@sifive.com>,
	Jim Wilson <jim.wilson.gcc@gmail.com>,
	Nelson Chu <nelson@rivosinc.com>,
	Kito Cheng <kito.cheng@sifive.com>
Cc: binutils@sourceware.org
Subject: [RFC PATCH 0/3] RISC-V: Add complex extension implications (incl. 'C'+'[FD]')
Date: Thu, 27 Jul 2023 00:30:18 +0000	[thread overview]
Message-ID: <cover.1690417818.git.research_trasio@irq.a4lg.com> (raw)

Hi,

This patch set reflects rather complex implications derived from 'C' and
either 'F' or 'D'.



[PATCH 1-2]

They are the expansions related in this context:

'C'             == 'C' + 'Zca'
'C' + 'F'       == 'C' + 'Zca' + 'Zcf'         + 'F' (RV32)
'C' + 'F'       == 'C' + 'Zca'                 + 'F' (RV64)
'C' + 'F' + 'D' == 'C' + 'Zca' + 'Zcf' + 'Zcd' + 'F' + 'D' (RV32)
'C' + 'F' + 'D' == 'C' + 'Zca'         + 'Zcd' + 'F' + 'D' (RV64)
(they exclude dependencies from 'F' and 'D')

I first thought implementing this is hard (as the implication list get
more complex).  However, thanks to the commit 48558a5e5471 ("RISC-V: Allow
nested implications for extensions"), things got a lot easier (we have an
option to rescan the implication list).  I haven't depended on this looping
behavior in *this* patch set but this loop will be useful in the future.

All we have to do is:

1.  Give more information to "check_func" when checking an
    implied extension and
2.  Implement custom "check_func" for such conditions.

"check_implicit_for_d_c" corresponds to the implication 'D' -> 'Zcd' and
returns true if the extension 'C' is *also* available.
It makes following expansions:

1.  'C'       == 'C'
2.  'C' + 'D' == 'C' + 'Zcd' + 'D'

"check_implicit_for_f_c" (which corresponds to the implication 'F' -> 'Zcf')
depends on "check_implicit_for_d_c" but does extra XLEN check (returns true
only when XLEN == 32).  It makes following expansions:

1.  'C'       == 'C'
2a. 'C' + 'F' == 'C' + 'Zcf' + 'F' (RV32)
2b. 'C' + 'F' == 'C'         + 'F' (RV64)

Existing "check_implicit_always" does following expansion:

1.  'C' == 'C' + 'Zca'

With all three combined, we can get the full expansions I listed above.



[PATCH 3]

It also requires some changes to the ".option norvc" half-deprecated (or
completely deprecated?) compatibility directive in the assembler.

I stated that it disables the 'C' extension and its subsets ('Zca', 'Zcf'
and 'Zcd').  If some extensions depend on 'C' or 'Zc*' are enabled, we
cannot emit compressed instructions but some garbage will remain in the
RISC-V attributes and mapping symbols.

Quick Example:

    .attribute arch, "rv32i"
    .option rvc
    .option arch, +zcb
    # ...
    .option norvc
    # The final architecture string will contain 'Zcb' (not disabled by
    # the ".option norvc" directive) and 'Zca' ('Zcb' depends on it).



[Others may need this change]

For instance, the draft 'Zicfiss' extension in the RISC-V CFI specification
draft might need this kind of complex implications.  This is because, not
only the instructions in that extension depends on the existence of
compressed instructions, uncompressed/compressed encodings of the extension
depend on 'Zimop' (uncompressed) and 'Zcmop' (compressed), respectively.

cf.
<https://github.com/riscv/riscv-cfi> (for 'Zicfiss')
<https://github.com/riscv/riscv-cfi/issues/131> (for 'Zimop' and 'Zcmop')

'Zicfiss'-related dependency:

*   'Zicfiss' (uncompressed encodings) -> 'Zimop'
*   'Zicfiss' (compressed encodings)   -> 'Zcmop' -> 'Zca'
(compressed forms must be enabled when either 'C' or 'Zca' is enabled.)

Example implementing the dependency using complex implications
                           (assuming this patch set is applied):

1.  'Zicfiss' -> 'Zimop'
2.  'Zicfiss' + 'Zca' -> 'Zcmop' (check 'Zca' in custom "check_func")
3.  'Zcmop' -> 'Zca'



[My Thoughts]

I had to modify some test cases that use ".option arch, -c" to disable
compressed instructions because ".option arch, -c" alone will not turn off
its subsets.  It suggests that this kind of behavior might be possibly
breaking on some programs.

We should monitor the situation and investigate existing programs to
minimize breaking others' work.

That's why this patch set is now an RFC
(despite that it's ready for the upstream merge; especially PATCH 1).



Thanks,
Tsukasa




Tsukasa OI (3):
  RISC-V: Base for complex extension implications
  RISC-V: Add complex implications from 'C'+'[DF]'
  RISC-V: ".option norvc" to disable 'C' and subsets

 bfd/elfxx-riscv.c                             | 66 +++++++++++++++----
 gas/config/tc-riscv.c                         |  6 +-
 gas/testsuite/gas/riscv/attribute-10.d        |  2 +-
 .../gas/riscv/dis-addr-overflow-32.d          |  2 +-
 .../gas/riscv/dis-addr-overflow-64.d          |  2 +-
 gas/testsuite/gas/riscv/dis-addr-overflow.s   |  4 +-
 gas/testsuite/gas/riscv/mapping-symbols.d     | 22 +++----
 gas/testsuite/gas/riscv/mapping.s             | 48 +++++++-------
 gas/testsuite/gas/riscv/march-imply-c-d-32.d  |  6 ++
 gas/testsuite/gas/riscv/march-imply-c-d-64.d  |  6 ++
 gas/testsuite/gas/riscv/march-imply-c.d       |  6 ++
 gas/testsuite/gas/riscv/march-ok-reorder.d    |  2 +-
 gas/testsuite/gas/riscv/option-arch-01.s      |  4 +-
 gas/testsuite/gas/riscv/option-arch-01b.d     |  2 +-
 gas/testsuite/gas/riscv/option-arch-02.d      |  2 +-
 gas/testsuite/gas/riscv/option-arch-02.s      |  4 +-
 gas/testsuite/gas/riscv/option-arch-03.d      |  2 +-
 gas/testsuite/gas/riscv/option-arch-03.s      |  4 +-
 18 files changed, 125 insertions(+), 65 deletions(-)
 create mode 100644 gas/testsuite/gas/riscv/march-imply-c-d-32.d
 create mode 100644 gas/testsuite/gas/riscv/march-imply-c-d-64.d
 create mode 100644 gas/testsuite/gas/riscv/march-imply-c.d


base-commit: 513c7e5f3e859be8670c7aa7aae41f78f860918f
-- 
2.41.0


             reply	other threads:[~2023-07-27  0:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-27  0:30 Tsukasa OI [this message]
2023-07-27  0:30 ` [RFC PATCH 1/3] RISC-V: Base for complex extension implications Tsukasa OI
2023-07-27  0:30 ` [RFC PATCH 2/3] RISC-V: Add complex implications from 'C'+'[DF]' Tsukasa OI
2023-07-27  0:30 ` [RFC PATCH 3/3] RISC-V: ".option norvc" to disable 'C' and subsets Tsukasa OI

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=cover.1690417818.git.research_trasio@irq.a4lg.com \
    --to=research_trasio@irq.a4lg.com \
    --cc=andrew@sifive.com \
    --cc=binutils@sourceware.org \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=kito.cheng@sifive.com \
    --cc=nelson@rivosinc.com \
    --cc=palmer@dabbelt.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).