public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Christoph Müllner" <christoph.muellner@vrull.eu>
To: Palmer Dabbelt <palmer@rivosinc.com>
Cc: gcc-patches@gcc.gnu.org,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	 Kito Cheng <kito.cheng@sifive.com>,
	Vedvyas Shanbhogue <ved@rivosinc.com>,
	 Nelson Chu <nelson@rivosinc.com>,
	Jeff Law <jeffreyalaw@gmail.com>
Subject: Re: [PATCH] RISC-V: Add the Zihpm and Zicntr extensions
Date: Fri, 18 Nov 2022 03:14:18 +0100	[thread overview]
Message-ID: <CAEg0e7jWrUov3MGVoOf7vZkEas=nZeoZkcbFAQ8vyvWE3iVcvA@mail.gmail.com> (raw)
In-Reply-To: <20221109030036.19175-1-palmer@rivosinc.com>

[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]

On Wed, Nov 9, 2022 at 4:01 AM Palmer Dabbelt <palmer@rivosinc.com> wrote:

> These extensions were recently frozen [1].  As per Andrew's post [2]
> we're meant to ignore these in software, this just adds them to the list
> of allowed extensions and otherwise ignores them.  I added these under
> SPEC_CLASS_NONE even though the PDF lists them as 20190614 because it
> seems pointless to add another spec class just to accept two extensions
> we then ignore.
>
> 1:
> https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/HZGoqP1eyps/m/GTNKRLJoAQAJ
> 2:
> https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/QKjQhChrq9Q/m/7gqdkctgAgAJ
>
> gcc/ChangeLog
>
>         * common/config/riscv/riscv-common.cc: Add Zihpm and Zicnttr
>         extensions.
>
> ---
>
> These deserves documentation, a test case, and a NEWS entry.  I didn't
> write those yet because it's not super clear this is the way we wanted
> to go, though: just flat out ignoring the ISA feels like the wrong thing
> to do, but the guidance here is pretty clear.  Still feels odd, though.
>


We already have the infrastructure in GAS to check the CSR numbers.
It is an optional feature, but it is here and working.
We follow the guidance in the default configuration (CSR checking needs to
be turned on).
As long as we want to keep this infrastructure, there is no question if we
should continue
to support new extensions as required by this feature:
We have to because everything else will lead to a broken feature.

The question if CSR checking in GAS should be removed or not does not have
to be
answered right now if there is doubt about making the wrong decision.

Additionally, I fully agree that we can not ignore unknown extensions.
We must report an unknown extension in the march string to the user.
And even without CSR checking, GCC needs to be aware of all extensions
(e.g. for possible future support of -march=native).

So I think this patch should go in (together with a test).

That's why I also sent something similar for Smaia and Ssaia:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606640.html

BR
Christoph





> We've also still got an open discussion on how we want to handle -march
> going forwards that's pretty relevant here, so I figured it'd be best to
> send this out sooner rather than later as it's sort of related.
> ---
>  gcc/common/config/riscv/riscv-common.cc | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/gcc/common/config/riscv/riscv-common.cc
> b/gcc/common/config/riscv/riscv-common.cc
> index 4b7f777c103..72981f05ac7 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -190,6 +190,9 @@ static const struct riscv_ext_version
> riscv_ext_version_table[] =
>    {"zicbom",ISA_SPEC_CLASS_NONE, 1, 0},
>    {"zicbop",ISA_SPEC_CLASS_NONE, 1, 0},
>
> +  {"zicntr", ISA_SPEC_CLASS_NONE, 2, 0},
> +  {"zihpm",  ISA_SPEC_CLASS_NONE, 2, 0},
> +
>    {"zk",    ISA_SPEC_CLASS_NONE, 1, 0},
>    {"zkn",   ISA_SPEC_CLASS_NONE, 1, 0},
>    {"zks",   ISA_SPEC_CLASS_NONE, 1, 0},
> --
> 2.38.1
>
>

  reply	other threads:[~2022-11-18  2:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-09  3:00 Palmer Dabbelt
2022-11-18  2:14 ` Christoph Müllner [this message]
2022-11-18  4:29   ` Palmer Dabbelt
2022-11-20 16:19 ` Jeff Law
2022-11-21  1:36   ` Kito Cheng
2022-11-22 15:20     ` Jeff Law
2022-11-22 15:29       ` Palmer Dabbelt
2022-11-22 21:50         ` Jeff Law
2022-11-22 22:00           ` Palmer Dabbelt
2024-01-19  8:01             ` Kito Cheng

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='CAEg0e7jWrUov3MGVoOf7vZkEas=nZeoZkcbFAQ8vyvWE3iVcvA@mail.gmail.com' \
    --to=christoph.muellner@vrull.eu \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=kito.cheng@sifive.com \
    --cc=nelson@rivosinc.com \
    --cc=palmer@rivosinc.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=ved@rivosinc.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).