From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 13E963858D39 for ; Thu, 29 Jun 2023 07:53:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 13E963858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1468AC14; Thu, 29 Jun 2023 00:54:33 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5CF5D3F73F; Thu, 29 Jun 2023 00:53:48 -0700 (PDT) From: Richard Sandiford To: Robin Dapp via Gcc-patches Mail-Followup-To: Robin Dapp via Gcc-patches , =?utf-8?B?6ZKf5bGF5ZOy?= , Jeff Law , Robin Dapp , "kito.cheng" , "kito.cheng" , palmer , palmer , richard.sandiford@arm.com Cc: =?utf-8?B?6ZKf5bGF5ZOy?= , Jeff Law , Robin Dapp , "kito.cheng" , "kito.cheng" , palmer , palmer Subject: Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI References: <20230628094752.332289-1-juzhe.zhong@rivai.ai> <59DD619A76E2AC1A+2023062903025467496516@rivai.ai> <0f48c2b7-a24d-6223-3805-d755c8eb7a7c@gmail.com> Date: Thu, 29 Jun 2023 08:53:47 +0100 In-Reply-To: (Richard Sandiford's message of "Wed, 28 Jun 2023 21:42:51 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-27.2 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: Richard Sandiford writes: > Robin Dapp via Gcc-patches writes: >> Hi Juzhe, >> >> I find the bug description rather confusing. What I can see is that >> the constant in the literal pool is indeed wrong but how would DSE or >> so play a role there? Particularly only for the smaller modes? >> >> My suspicion would be that the constant in the literal/constant pool >> is wrong from start to finish. >> >> I just played around with the following hunk: >> >> diff --git a/gcc/varasm.cc b/gcc/varasm.cc >> index 542315f88cd..5223c08924f 100644 >> --- a/gcc/varasm.cc >> +++ b/gcc/varasm.cc >> @@ -4061,7 +4061,7 @@ output_constant_pool_2 (fixed_size_mode mode, rtx x, unsigned int align) >> whole element. Often this is byte_mode and contains more >> than one element. */ >> unsigned int nelts = GET_MODE_NUNITS (mode); >> - unsigned int elt_bits = GET_MODE_BITSIZE (mode) / nelts; >> + unsigned int elt_bits = GET_MODE_PRECISION (mode) / nelts; >> unsigned int int_bits = MAX (elt_bits, BITS_PER_UNIT); >> scalar_int_mode int_mode = int_mode_for_size (int_bits, 0).require (); >> >> With this all your examples pass for me. We then pack e.g. 16 VNx2BI elements >> into an int and not just 8. It would also explain why it works for modes >> where PRECISION == BITSIZE. Now it will certainly require a more thorough >> analysis but maybe it's a start? > > Yeah. Preapproved for trunk & any necessary branches. Sorry, only realised later, but: if the precision can cover fewer bytes than the bitsize, I suppose there ought to be some zero-byte padding at the end as well. Thanks, Richard