From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 7BD053857359 for ; Thu, 2 Jun 2022 13:17:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7BD053857359 Received: by mail-ej1-x62b.google.com with SMTP id rs12so9876736ejb.13 for ; Thu, 02 Jun 2022 06:17:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oe8rw1l9u7ThLLLD9kUFOZhLrhJg+v+Ur3Q5iGBoiSE=; b=yhIDgqIFxRAlU2OzRDUNqFR2/W7L76kSy5vTxCP9ew53zthoKbQCK3K4wRQVSOOGbw fwmCD/F31wMWrT2WkI/Xb9qGvUlJx3V/KGK44grAFhrqDk/NteI7EzXF4se7xnd9AYer MCiyJbdrW+iMgf1YHw+Pdhj3ty+X3COvoFUzlFz8O472Wc6t5JDO3AYGwjn8phi9Nhez u2JWhwqwnA2xlmo86phQtLJF+Yw+CR9SQDFJkvvMdX0Frn++B+9ccpDkkKHEC4AYVojg lZRGioumeVHEll1byr1c7RCxQ9GidajGb5kwAucR8ElgPCwiom71RaxJdqSeSCuZ//+r cnqw== X-Gm-Message-State: AOAM530upD8PmJQRmDR8YgFOJ805ipCdTxv/ViBqsCizaFwooPmveAaH fXHAWyyFv0hIkNkzNySBzciML14FwxSAi6UCkfU= X-Google-Smtp-Source: ABdhPJxHWPLQgV8McB/Xf23tbc3gp+hRO7Lv1lf4Otdlona29hPnFZG5b9fDVzY0LcleGG6pbRXqhpZbeoS7kLj/EYg= X-Received: by 2002:a17:907:7ea9:b0:6fe:d412:ec2c with SMTP id qb41-20020a1709077ea900b006fed412ec2cmr4236321ejc.613.1654175841990; Thu, 02 Jun 2022 06:17:21 -0700 (PDT) MIME-Version: 1.0 References: <20220529215127.482180-1-philipp.tomsich@vrull.eu> In-Reply-To: <20220529215127.482180-1-philipp.tomsich@vrull.eu> From: Kito Cheng Date: Thu, 2 Jun 2022 21:17:09 +0800 Message-ID: Subject: Re: [PATCH v2] RISC-V: bitmanip: improve constant-loading for (1ULL << 31) in DImode To: Philipp Tomsich Cc: GCC Patches , Vineet Gupta Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2022 13:17:25 -0000 LGTM On Mon, May 30, 2022 at 5:52 AM Philipp Tomsich wrote: > > The SINGLE_BIT_MASK_OPERAND() is overly restrictive, triggering for > bits above 31 only (to side-step any issues with the negative SImode > value 0x80000000/(-1ull << 31)/(1 << 31)). This moves the special > handling of this SImode value (i.e. the check for (-1ull << 31) to > riscv.cc and relaxes the SINGLE_BIT_MASK_OPERAND() test. > > With this, the code-generation for loading (1ULL << 31) from: > li a0,1 > slli a0,a0,31 > to: > bseti a0,zero,31 > > gcc/ChangeLog: > > * config/riscv/riscv.cc (riscv_build_integer_1): Rewrite value as > (-1 << 31) for the single-bit case, when operating on (1 << 31) > in SImode. > * gcc/config/riscv/riscv.h (SINGLE_BIT_MASK_OPERAND): Allow for > any single-bit value, moving the special case for (1 << 31) to > riscv_build_integer_1 (in riscv.c). > > Signed-off-by: Philipp Tomsich > > --- > > Changes in v2: > - Use HOST_WIDE_INT_1U/HOST_WIDE_INT_M1U instead of constants. > - Fix some typos in the comment above the rewrite of the value. > - Update the comment to clarify that we expect a LUI to be emitted for > the SImode case (i.e. sign-extended for RV64) of (1 << 31). > > gcc/config/riscv/riscv.cc | 9 +++++++++ > gcc/config/riscv/riscv.h | 11 ++++------- > 2 files changed, 13 insertions(+), 7 deletions(-) > > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc > index f83dc796d88..2e83ca07394 100644 > --- a/gcc/config/riscv/riscv.cc > +++ b/gcc/config/riscv/riscv.cc > @@ -420,6 +420,15 @@ riscv_build_integer_1 (struct riscv_integer_op codes[RISCV_MAX_INTEGER_OPS], > /* Simply BSETI. */ > codes[0].code = UNKNOWN; > codes[0].value = value; > + > + /* RISC-V sign-extends all 32bit values that live in a 32bit > + register. To avoid paradoxes, we thus need to use the > + sign-extended (negative) representation (-1 << 31) for the > + value, if we want to build (1 << 31) in SImode. This will > + then expand to an LUI instruction. */ > + if (mode == SImode && value == (HOST_WIDE_INT_1U << 31)) > + codes[0].value = (HOST_WIDE_INT_M1U << 31); > + > return 1; > } > > diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h > index 5083a1c24b0..6f7f4d3fbdc 100644 > --- a/gcc/config/riscv/riscv.h > +++ b/gcc/config/riscv/riscv.h > @@ -528,13 +528,10 @@ enum reg_class > (((VALUE) | ((1UL<<31) - IMM_REACH)) == ((1UL<<31) - IMM_REACH) \ > || ((VALUE) | ((1UL<<31) - IMM_REACH)) + IMM_REACH == 0) > > -/* If this is a single bit mask, then we can load it with bseti. But this > - is not useful for any of the low 31 bits because we can use addi or lui > - to load them. It is wrong for loading SImode 0x80000000 on rv64 because it > - needs to be sign-extended. So we restrict this to the upper 32-bits > - only. */ > -#define SINGLE_BIT_MASK_OPERAND(VALUE) \ > - (pow2p_hwi (VALUE) && (ctz_hwi (VALUE) >= 32)) > +/* If this is a single bit mask, then we can load it with bseti. Special > + handling of SImode 0x80000000 on RV64 is done in riscv_build_integer_1. */ > +#define SINGLE_BIT_MASK_OPERAND(VALUE) \ > + (pow2p_hwi (VALUE)) > > /* Stack layout; function entry, exit and calling. */ > > -- > 2.34.1 >