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 9A1CE3858D37 for ; Mon, 13 Feb 2023 10:18:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9A1CE3858D37 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 DEC0E1FCD; Mon, 13 Feb 2023 02:19:39 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 620483F703; Mon, 13 Feb 2023 02:18:56 -0800 (PST) From: Richard Sandiford To: "juzhe.zhong\@rivai.ai" Mail-Followup-To: "juzhe.zhong\@rivai.ai" ,rguenther , incarnation.p.lee , gcc-patches , Kito.cheng , ams , richard.sandiford@arm.com Cc: rguenther , incarnation.p.lee , gcc-patches , Kito.cheng , ams Subject: Re: [PATCH] RISC-V: Bugfix for mode tieable of the rvv bool types References: <869B9CDC6210FDAD+20230213161951079936108@rivai.ai> <5CDAF1EC0059903D+20230213174828831645116@rivai.ai> Date: Mon, 13 Feb 2023 10:18:55 +0000 In-Reply-To: <5CDAF1EC0059903D+20230213174828831645116@rivai.ai> (juzhe's message of "Mon, 13 Feb 2023 17:48:29 +0800") 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=-29.3 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP 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: "juzhe.zhong@rivai.ai" writes: >>> What's the byte size of VNx1BI, expressed as a function of N? >>> If it's CEIL (N, 8) then we don't have a way of representing that yet. > N is a poly value. > RVV like SVE support scalable vector. > the N is poly (1,1). > > VNx1B mode nunits = poly(1,1) units. > VNx1B mode bitsize =poly (1,1) bitsize. > VNx1B mode bytesize = poly(1,1) units (currently). Ideally and more accurate, it should be VNx1B mode bytesize =poly (1/8,1/8). But this would be a fractional bytesize, and like Richard says, the memory subsystem would always access full bytes. So I think the bytesize would have to be at least CEIL (N, 8). > However, it can't represent it like this. GCC consider its bytesize as poly (1,1) bytesize. Ah, OK. That (making the size N bytes) does seem like a reasonable workaround, provided that it matches the C types, etc. So the total amount of padding is 7N bits (I assume at the msb of the type when viewed as an integer). I agree that what (IIUC) was discussed upthread works, i.e.: bytesize = N bitsize = N * 8 (fixed function of bytesize) precision = N nunits = N unit_size = 1 unit_precision = 1 But target-independent code won't expect this layout, so supporting it will involve more than just adjusting the parameters. Thanks, Richard