public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Philipp Tomsich <philipp.tomsich@vrull.eu>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>,
	gcc-patches@gcc.gnu.org,  Vineet Gupta <vineetg@rivosinc.com>,
	christoph.muellner@vrull.eu,  Kito Cheng <kito.cheng@gmail.com>,
	jlaw@ventanamicro.com
Subject: Re: [PATCH 4/7] RISC-V: Recognize sign-extract + and cases for XVentanaCondOps
Date: Fri, 18 Nov 2022 15:41:35 +0100	[thread overview]
Message-ID: <CAAeLtUBvLDsqvqk5pYg8m4V_PTqGCYeU2pE1PPk2EMyWaf8XTA@mail.gmail.com> (raw)
In-Reply-To: <5257682e-7ec7-8fa6-3e63-495e6776c09d@gmail.com>

On Fri, 18 Nov 2022 at 15:34, Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
> On 11/17/22 16:56, Palmer Dabbelt wrote:
> > On Thu, 17 Nov 2022 15:41:26 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> >>
> >> On 11/12/22 14:29, Philipp Tomsich wrote:
> >>> Users might use explicit arithmetic operations to create a mask and
> >>> then and it, in a sequence like
> >>>      cond = (bits >> SHIFT) & 1;
> >>>      mask = ~(cond - 1);
> >>>      val &= mask;
> >>> which will present as a single-bit sign-extract.
> >>>
> >>> Dependening on what combination of XVentanaCondOps and Zbs are
> >>> available, this will map to the following sequences:
> >>>   - bexti + vt.maskc, if both Zbs and XVentanaCondOps are present
> >>>   - andi + vt.maskc, if only XVentanaCondOps is available and the
> >>>                      sign-extract is operating on bits 10:0 (bit
> >>>             11 can't be reached, as the immediate is
> >>>             sign-extended)
> >>>   - slli + srli + and, otherwise.
> >>>
> >>> gcc/ChangeLog:
> >>>
> >>>     * config/riscv/xventanacondops.md: Recognize SIGN_EXTRACT
> >>>       of a single-bit followed by AND for XVentanaCondOps.
> >>>
> >>> Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
> >>> ---
> >>>
> >>>   gcc/config/riscv/xventanacondops.md | 46
> >>> +++++++++++++++++++++++++++++
> >>>   1 file changed, 46 insertions(+)
> >>>
> >>> diff --git a/gcc/config/riscv/xventanacondops.md
> >>> b/gcc/config/riscv/xventanacondops.md
> >>> index 7930ef1d837..3e9d5833a4b 100644
> >>> --- a/gcc/config/riscv/xventanacondops.md
> >>> +++ b/gcc/config/riscv/xventanacondops.md
> >>> @@ -73,3 +73,49 @@
> >>>     "TARGET_XVENTANACONDOPS"
> >>>     [(set (match_dup 5) (match_dup 1))
> >>>      (set (match_dup 0) (and:X (neg:X (ne:X (match_dup 5) (const_int
> >>> 0)))
> >>> +
> >>> +;; Users might use explicit arithmetic operations to create a mask and
> >>> +;; then and it, in a sequence like
> >>
> >> Nit.  Seems like a word is missing.  "make and then and it"??
> >>
> >>
> >> Do we really care about TARGET_XVENTANACONDOPS && ! TARGET_ZBS?
> >
> > I guess that's really more of a question for the Ventana folks, but
> > assuming all the Ventana widgets have Zbs then it seems reasonable to
> > just couple them -- there's already enough options in RISC-V land to
> > test everything, might as well make sure what slips through the cracks
> > isn't being built.
>
> I'm pretty confident Ventana won't be making a part without Zbs which is
> why I raised the issue
>
>
> I also understand Philipp's position that one could explicitly turn on
> ventanacondops and zbs off and that there's a notable possibility that
> this ultimately turns into ZICondOps independent of Ventana.
>
>
> So I guess we keep it...  But it also feels like a ticking time bomb WRT
> the ability to mix and match things the way we currently allow.  I
> suspect if we were to look at the full test matrix and deeply test that
> full matrix that we'd find a number of problems where two options
> interact badly.

I have been worrying about the exponential growth of the test matrix
for 2 years now and still haven't come up with a good solution. It is
clear that this is a challenge for the entire RISC-V ecosystem and
that it needs to be addressed across vendors and across the entire
membership: unfortunately, that doesn't make for an easier path to a
solution.

And just as an aside: pure extensions are still less worrisome than
subtractive changes (think Zfinx and Zdinx), or the fact that we have
different options for the memory model (RVWMO vs. Ztso), or variations
in regard to what facilities are available for atomics...


Philipp.

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

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-12 21:29 [PATCH 0/7] RISC-V: Backend support for XVentanaCondOps/ZiCondops Philipp Tomsich
2022-11-12 21:29 ` [PATCH 1/7] RISC-V: Recognize xventanacondops extension Philipp Tomsich
2022-11-17 22:46   ` Jeff Law
2022-11-12 21:29 ` [PATCH 2/7] RISC-V: Generate vt.maskc<n> on noce_try_store_flag_mask if-conversion Philipp Tomsich
2022-11-17 22:49   ` Jeff Law
2022-11-12 21:29 ` [PATCH 3/7] RISC-V: Support noce_try_store_flag_mask as vt.maskc<n> Philipp Tomsich
2022-11-17 23:12   ` Jeff Law
2022-11-12 21:29 ` [PATCH 4/7] RISC-V: Recognize sign-extract + and cases for XVentanaCondOps Philipp Tomsich
2022-11-17 23:41   ` Jeff Law
2022-11-17 23:56     ` Palmer Dabbelt
2022-11-18  0:10       ` Philipp Tomsich
2022-11-18 14:34       ` Jeff Law
2022-11-18 14:41         ` Philipp Tomsich [this message]
2022-11-18  0:08     ` Philipp Tomsich
2022-11-12 21:29 ` [PATCH 5/7] RISC-V: Recognize bexti in negated if-conversion Philipp Tomsich
2022-11-17 23:17   ` Jeff Law
2022-11-12 21:29 ` [PATCH 6/7] RISC-V: Support immediates in XVentanaCondOps Philipp Tomsich
2022-11-17 23:36   ` Jeff Law
2022-11-12 21:29 ` [PATCH 7/7] ifcvt: add if-conversion to conditional-zero instructions Philipp Tomsich
2022-11-12 21:47   ` Andrew Pinski
2022-11-12 22:01     ` Philipp Tomsich

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=CAAeLtUBvLDsqvqk5pYg8m4V_PTqGCYeU2pE1PPk2EMyWaf8XTA@mail.gmail.com \
    --to=philipp.tomsich@vrull.eu \
    --cc=christoph.muellner@vrull.eu \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=jlaw@ventanamicro.com \
    --cc=kito.cheng@gmail.com \
    --cc=palmer@rivosinc.com \
    --cc=vineetg@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).