From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 5F1333858D1E for ; Sat, 6 May 2023 00:31:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F1333858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1aaf2ede38fso23272795ad.2 for ; Fri, 05 May 2023 17:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683333063; x=1685925063; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=GirfUZtJA4aCx3bx41M3T/BuNHVvX6PYxnj+tssTwVU=; b=joDjF4hHG3EBdgpFQK4YmskorS5A3dHXS/mkRBgaBw+rE/HurRjzgh0Prtle2tzZmj chVQp6MER+JWAM02MpCReKhlCDrykRimjEet/Ut/gpOibPqW+1Nx4/1Cioc3rA5/84rZ 9zzDHm27TgNzqR9++QD7uSmu4D/HlhKeWWqyHAUFZKc6OtCpUape9ZbihrtVdVOI8Lji ztaoiKZ5ZOrQIG+cRLMB38QQQOOplXJtetfR0oDBxziCSCsU2Z4OamI5W17ZNh44b/Lj pliAysLZ/2VU3v075Cn/JUvRJM3YtmRzzcWZCulmbGY5vrUQbXwYYBD+rbamf1++NR6X fOzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683333063; x=1685925063; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GirfUZtJA4aCx3bx41M3T/BuNHVvX6PYxnj+tssTwVU=; b=U82nmb3izT+6PzQECyvygKm9R6LNcZbZHLXLcIiOYOPYBbZzE8WzAn9zSPvw24Zius 8u8Lg5Lq8JMCacI/Zdr2Ip8YkVokJoB+Va7sZfydINJVHAYoX+RtZU2Q1tfMfvY0W1/h PwFlGdZP21BeTCTPSy/TclpNYm1KoaftiR3JeVLD/VXdlocCrGuk2joi0LZK87NkLiJH OUtkxFgySMlQvbxVC///3815QqqjebOJ5TRBmmtlKRpY+QWXpe6qCKXgPdYCQJkPHWwb FSdCT3YB9wTSqhZNl7barGss+8MCvnYcumgPQBl2SfyPywzLJyWNELNfVp/rprR6taPl su9w== X-Gm-Message-State: AC+VfDzIXDyodwsSUOputBRhHJu4w/zXOvHldEGKEl91FE2FOrBI1K2g LoUIGFncJL/hQMeIrY1+yfc= X-Google-Smtp-Source: ACHHUZ5F9agukkKiEur1skfvm+CrNIRLvwr8w8hepC9734VPlh8pzkiOd+Vz3Gzyk0G6koaEsSIsKQ== X-Received: by 2002:a17:902:e810:b0:1a1:f5dd:2dce with SMTP id u16-20020a170902e81000b001a1f5dd2dcemr4014315plg.6.1683333063072; Fri, 05 May 2023 17:31:03 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id f13-20020a170902ab8d00b001aaea39043dsm2316746plr.41.2023.05.05.17.31.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 May 2023 17:31:02 -0700 (PDT) Message-ID: Date: Fri, 5 May 2023 18:31:01 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH] RISC-V: Add bext pattern for ZBS Content-Language: en-US To: Raphael Moreira Zinsly , gcc-patches@gcc.gnu.org References: <20230504170808.1829411-1-rzinsly@ventanamicro.com> From: Jeff Law In-Reply-To: <20230504170808.1829411-1-rzinsly@ventanamicro.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 5/4/23 11:08, Raphael Moreira Zinsly wrote: > When (a & (1 << bit_no)) is tested inside an IF we can use a bit extract. > > gcc/ChangeLog: > > * config/riscv/bitmanip.md > (bext): Rename one to avoid name clash. > (branch_bext): New split pattern. > > gcc/testsuite/ChangeLog: > * gcc.target/riscv/zbs-bext-02.c: New test. > --- > gcc/config/riscv/bitmanip.md | 24 +++++++++++++++++++- > gcc/testsuite/gcc.target/riscv/zbs-bext-02.c | 18 +++++++++++++++ > 2 files changed, 41 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/gcc.target/riscv/zbs-bext-02.c > > diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md > index a27fc3e34a1..e29e2d1fa53 100644 > --- a/gcc/config/riscv/bitmanip.md > +++ b/gcc/config/riscv/bitmanip.md > @@ -595,7 +595,7 @@ > ;; When performing `(a & (1UL << bitno)) ? 0 : -1` the combiner > ;; usually has the `bitno` typed as X-mode (i.e. no further > ;; zero-extension is performed around the bitno). > -(define_insn "*bext" > +(define_insn "*bext_2" > [(set (match_operand:X 0 "register_operand" "=r") > (zero_extract:X (match_operand:X 1 "register_operand" "r") > (const_int 1) This doesn't make sense to me. Is it possible this was from an earlier version of the patch? In general when we have a * prefix, we're allowed to have multiple patterns with the same name. Essentially the pattern names are just for debugging purposes, no API is exposed to generate those patterns when there's a '*' prefix. > @@ -720,6 +720,28 @@ > operands[9] = GEN_INT (clearbit); > }) > > +;; IF_THEN_ELSE: test for (a & (1 << BIT_NO)) > +(define_insn_and_split "*branch_bext" > + [(set (pc) > + (if_then_else > + (match_operator 1 "equality_operator" > + [(zero_extract:X (match_operand:X 2 "register_operand" "r") > + (const_int 1) > + (zero_extend:X (match_operand:QI 3 "register_operand" "r"))) > + (const_int 0)]) > + (label_ref (match_operand 0 "" "")) > + (pc))) > + (clobber (match_scratch:X 4 "=&r"))] Formatting nit. In general the operands of a rtx operator all line up together when we can. So in this case the (const_int 1) should line up under the (match_operand:X 2). Similarly for the (zero_extend:X). That may require wrapping the zero_extned line. The way to do that would be to bring its match_operand down to a new line, indent it two spaces from the open paren of the (zero_extend. It's been a while since we poked at this, so maybe you've already told me before, but would it make sense to use the GPR iterator rather than the X iterator? GPR would result in two patterns that are available to match at the same time, one for SI, another for DI. X also results in two patterns, but only one is available at any given time dependent on TARGET_64BIT. I guess the rest are defined in terms of X, particularly the bext pattern. So nevermind, keep it as X. So I think the only things we potentially adjust is to remove the hunk which changes the name of the *bext pattern and the whitespace fix. I think we'll be good to go after those changes. Jeff