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 357BD3858D33 for ; Thu, 13 Apr 2023 13:07:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 357BD3858D33 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 49BEC2F4; Thu, 13 Apr 2023 06:07:44 -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 C28F73F73F; Thu, 13 Apr 2023 06:06:58 -0700 (PDT) From: Richard Sandiford To: =?utf-8?B?6ZKf5bGF5ZOy?= Mail-Followup-To: =?utf-8?B?6ZKf5bGF5ZOy?= ,kito.cheng , rguenther , "Jeff Law" , gcc-patches , palmer , jakub , richard.sandiford@arm.com Cc: kito.cheng , rguenther , "Jeff Law" , gcc-patches , palmer , jakub 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> <0AEFD2378C3DF89B+202304111919556577872@rivai.ai> <2978624D57874251+2023041307225185723242@rivai.ai> Date: Thu, 13 Apr 2023 14:06:57 +0100 In-Reply-To: <2978624D57874251+2023041307225185723242@rivai.ai> (=?utf-8?B?IumSn+WxheWTsiIncw==?= message of "Thu, 13 Apr 2023 07:22:52 +0800") 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=-23.6 required=5.0 tests=BAYES_00,BODY_8BITS,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: =E9=92=9F=E5=B1=85=E5=93=B2 writes: > Yeah, like kito said. > Turns out the tuple type model in ARM SVE is the optimal solution for RVV. > And we like ARM SVE style implmentation. > > And now we see swapping rtx_code and mode in rtx_def can make rtx_def ove= ral not exceed 64 bit. > But it seems that there is still problem in tree_type_common and tree_dec= l_common, is that right? I thought upthread we had a way forward for tree_type_common and tree_decl_common too, but maybe I only convinced myself. :) > After several trys (remove all redundant TI/TF vector modes and FP16 vect= or mode), now there are 252 modes > in RISC-V port. Basically, I can keep supporting new RVV intrinsisc featu= res recently. > However, we can't support more in the future, for example, FP16 vector, B= F16 vector, matrix modes, VLS modes,...etc. I agree it doesn't make sense to try to squeeze modes out like this. It's a bit artificial, and like you say, it's likely only putting off the inevitable. Thanks, Richard > > From RVV side, I think extending 1 more bit of machine mode should be eno= ugh for RVV (overal 512 modes). > Is it possible make it happen in tree_type_common and tree_decl_common, R= ichards? > > Thank you so much for all comments. > > > juzhe.zhong@rivai.ai