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 190E23858D20 for ; Tue, 11 Apr 2023 10:15:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 190E23858D20 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 339DED75; Tue, 11 Apr 2023 03:16:11 -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 A69E73F73F; Tue, 11 Apr 2023 03:15:25 -0700 (PDT) From: Richard Sandiford To: Richard Earnshaw Mail-Followup-To: Richard Earnshaw ,juzhe.zhong@rivai.ai, Jeff Law , gcc-patches , "kito.cheng" , palmer , jakub , rguenther , richard.sandiford@arm.com Cc: juzhe.zhong@rivai.ai, Jeff Law , gcc-patches , "kito.cheng" , palmer , jakub , rguenther Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit References: <20230410144808.324346-1-juzhe.zhong@rivai.ai> <89f088ec-8692-01f5-0395-5a66ddf085d7@gmail.com> <47D962C7C724E3A2+20230410231445834316202@rivai.ai> <9b3d5058-1110-8201-396a-84e18a6c038f@foss.arm.com> Date: Tue, 11 Apr 2023 11:15:24 +0100 In-Reply-To: <9b3d5058-1110-8201-396a-84e18a6c038f@foss.arm.com> (Richard Earnshaw's message of "Tue, 11 Apr 2023 11:05:25 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-25.2 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: Richard Earnshaw writes: > On 11/04/2023 10:46, Richard Sandiford via Gcc-patches wrote: >> writes: >>> ARM SVE has=EF=BC=9Asvint8_t, svint8x2_t, svint8x3_t, svint8x4_t >>> As far as I known, they don't have tuple type for partial vector. >>=20 >> Yeah, there are no separate types for partial vectors, but there >> are separate modes. E.g. VNx2QI is a partial vector of QIs, >> with each QI stored in a 64-bit container. >>=20 >> I agree with all the comments about the danger of growing the number of >> modes too much. But it looks like rtx_def should be easy to rearrange. >> Unless I'm missing something, there are less than 256 rtx codes at >> present. So one simple option would be to make the code 8 bits and >> the machine_mode 16 bits (and swap them, so that they stay well-aligned >> wrt their size). >>=20 >> That of course would create new problem if we want more than 256 codes >> in future. But then there would be the option of a non-power-of-2 >> split (12/12 or whatever). Also, it's possible to multiplex operations >> into a single code by adding an extra operand, whereas it's harder to >> multiplex modes. >>=20 >> Thanks, >> Richard > > The rtx code and mode are both accessed quite frequently, making them=20 > non-native machine sizes might have impact on the performance of=20 > accessing the fields. Yeah, that's why I suggested that having a subcode operand would be an alternative to abandoning non-power-of-2 sizes. It seems unlikely that any new codes we add now will be so frequently used that an extra operand would be a problem in terms of either size or speed. Having a subcode operand would be very much UNSPECs today. But as it is, we've added 9 new rtx codes in the last 10 years. So even with 203 at present, with the current rate of expansion, it would be at least the 2070s before this becomes an issue. Richard