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 13EDD3858415 for ; Thu, 29 Jun 2023 08:54:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 13EDD3858415 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 374F1C14; Thu, 29 Jun 2023 01:54:57 -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 79E8F3F663; Thu, 29 Jun 2023 01:54:12 -0700 (PDT) From: Richard Sandiford To: Robin Dapp Mail-Followup-To: Robin Dapp ,Robin Dapp via Gcc-patches , =?utf-8?B?6ZKf5bGF5ZOy?= , Jeff Law , "kito.cheng" , "kito.cheng" , palmer , palmer , richard.sandiford@arm.com Cc: Robin Dapp via Gcc-patches , =?utf-8?B?6ZKf?= =?utf-8?B?5bGF5ZOy?= , Jeff Law , "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> <85bfdc0a-6b55-a72c-b8d8-656b40b0003a@gmail.com> Date: Thu, 29 Jun 2023 09:54:11 +0100 In-Reply-To: <85bfdc0a-6b55-a72c-b8d8-656b40b0003a@gmail.com> (Robin Dapp's message of "Thu, 29 Jun 2023 10:14:08 +0200") 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=-21.2 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Robin Dapp writes: >> 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. > It looks like this problem, and also the padding, has been discussed > before when the precision of VNx1BI etc. was first adjusted in the > RISC-V backend? Very probably. Can't remember now. > I didn't immediately get the padding, though. So if we e.g. have a > VNx2BI constant {0, 1} what would we pad the resulting value "2" to? > A full byte? Yeah, that part is OK, and was the case I was thinking about when I said OK yesterday. But now that we allow BITSIZE != PRECISION, it's possible for BITSIZE - PRECISION to be more than a full byte, in which case the new loop would not initialise every byte of the mode. I vaguely remembered that that could happen for RVV_FIXED_VLMAX, but perhaps I misremember. If it can't happen then an assert would be OK instead. Thanks, Richard