From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from arjuna.pair.com (arjuna.pair.com [209.68.5.131]) by sourceware.org (Postfix) with ESMTPS id 72F10385772C for ; Sat, 15 Apr 2023 02:58:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 72F10385772C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bitrange.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bitrange.com Received: by arjuna.pair.com (Postfix, from userid 3006) id ACC5E8A657; Fri, 14 Apr 2023 22:58:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by arjuna.pair.com (Postfix) with ESMTP id A8C868A63B; Fri, 14 Apr 2023 22:58:13 -0400 (EDT) Date: Fri, 14 Apr 2023 22:58:13 -0400 (EDT) From: Hans-Peter Nilsson X-X-Sender: hp@arjuna.pair.com To: Richard Biener cc: Richard Sandiford , =?UTF-8?B?6ZKf5bGF5ZOy?= , "kito.cheng" , Jeff Law , gcc-patches , palmer , jakub Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit In-Reply-To: Message-ID: 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> User-Agent: Alpine 2.20.16 (BSF 172 2016-09-29) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: mailmunge 3.11 on 209.68.5.131 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,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: On Thu, 13 Apr 2023, Richard Biener via Gcc-patches wrote: > On Thu, 13 Apr 2023, Richard Sandiford wrote: > > > ??? 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 overal not exceed 64 bit. > > > But it seems that there is still problem in tree_type_common and tree_decl_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 vector mode), now there are 252 modes > > > in RISC-V port. Basically, I can keep supporting new RVV intrinsisc features recently. > > > However, we can't support more in the future, for example, FP16 vector, BF16 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. > > Agreed. Let's do the proposed TYPE_PRECISION change first and then > see how bad 16bit mode will be. (I don't see the following obvious having been pointed out, or why it doesn't apply, but if so, I hope you don't mind repeating it, so:) If after all, a change to the size of the code and mode bit-fields in rtx_def is necessary, like to still fit 64 bytes such become non-byte sizes *and* that matters for compilation time, can that change please be made target-dependent? Not as in set by a target macro, but rather deduced from the number of modes defined by the target? After all, that number is readily available (or if there's an order problem seems likely to easily be made available to the rtx_def build-time definition (as opposed to a gen-* -time definition). brgds, H-P