From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id E6227385841E for ; Fri, 18 Nov 2022 14:41:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E6227385841E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-lf1-x12b.google.com with SMTP id j4so8586472lfk.0 for ; Fri, 18 Nov 2022 06:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RXCZLBT6AuadlZlLtB+K7ingn2E2C9bGqrBn7FMqj9o=; b=QvMqLN8joE/e1fZTrNC3xKXWc8u1mqMjb3IzS4uPK8EYoGhq8TfkTarn/g2NAaQwEQ VU745qbGrvY3YU1879ITMOgRZIRtZTwpwHfPO8mPwin8SZGP/8tCa2YwKy6S7AGGIIsp GrtiE23KrWeRHr2b27iv3R1XnPlmNvJwxOMJeE4d5uNA2ul7lkItVZ1o62RKNeSAiaJQ AVpRDZXNULncA9nc7Qc5bXL2hUXnzNxGQ9ATC36oR07ALbhf3OT85zeBVWaiTYfU7fOq SzPQoBAACqv3tRxZR169ggDM8183xEC9SwK7rtZKviNYw98xnfqy83DOnYV//57wsOxc vZug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RXCZLBT6AuadlZlLtB+K7ingn2E2C9bGqrBn7FMqj9o=; b=OHb68khsCHyQpq0FIH9AEkXcKCKgGZD6wHn9ik3iPTiY9RjZwKXAEWGgIdSM8l09Dx qroaFaIAqGBz8z5mqgM3eYXMBR1RoiH7CrlgQmOLrOI+PHaVAFynDcZkM1TjfQ590b4d +chetZt7bE6On93znR2mVo4h0FZIX5nkAhRI30zYKveJmCtGyKREA8q8nl7TEl35otuV OFKkUq09uTtppfdhXmF3dbiFva274sNIzIAocD34k74nEAGJ7jjZxtG9GeByfQtmWZa0 +Vx193BakGWkXRK4vbHucSY806ENgT1rg9orPzrAJenhtPjvDQuJ6XJru2pawgUDGlnj sfmg== X-Gm-Message-State: ANoB5pkNRB2Q81UfWolEMIxw1cwPaNtWZscXUZCWYDg57l5asydIc8/i EDTL2x8UWpQwKtmRkMurUQ6P15D8xCs93nvmMY/xLA== X-Google-Smtp-Source: AA0mqf7hnR8aUCgQXHk560XssfAm1xwRSBCbJR4uF1Egq2TluVxqwbaNxt4cnk32SdemqGGzRQA3DMsdShF2LwLDS1c= X-Received: by 2002:ac2:4d83:0:b0:4a9:2ca6:c14b with SMTP id g3-20020ac24d83000000b004a92ca6c14bmr2806470lfe.163.1668782509332; Fri, 18 Nov 2022 06:41:49 -0800 (PST) MIME-Version: 1.0 References: <5257682e-7ec7-8fa6-3e63-495e6776c09d@gmail.com> In-Reply-To: <5257682e-7ec7-8fa6-3e63-495e6776c09d@gmail.com> From: Philipp Tomsich Date: Fri, 18 Nov 2022 15:41:35 +0100 Message-ID: Subject: Re: [PATCH 4/7] RISC-V: Recognize sign-extract + and cases for XVentanaCondOps To: Jeff Law Cc: Palmer Dabbelt , gcc-patches@gcc.gnu.org, Vineet Gupta , christoph.muellner@vrull.eu, Kito Cheng , jlaw@ventanamicro.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 18 Nov 2022 at 15:34, Jeff Law 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 > >>> --- > >>> > >>> 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.