From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 30591385770A for ; Mon, 17 Apr 2023 06:38:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 30591385770A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id A3C981F461; Mon, 17 Apr 2023 06:38:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1681713503; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=USDhYDHnM+baL46H2Iz8rXYZIefas33ugVwzi9JORvA=; b=qALyX0EUisMkcr3kz6oXbI67OOJ8202n5GwDePuVlB4uo+ieDXT69r3xG1dDQuIYkQlgVQ j6vCzcIUPmi2+/9oeMLy/w1DpdGq+irC5Gba23+5KeQBT9rPAB2A4VoDV/rDnvxyko5+Ls JAPt2qbaFjQQZ4/mgAb7a3/zoso9evA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1681713503; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=USDhYDHnM+baL46H2Iz8rXYZIefas33ugVwzi9JORvA=; b=Tif46XPOQhQjZmsK1MrvHLCvNPZlx7Gsf8tdvH8V5HtL5FvdsAP7T+qvNFfTa9lIRSb7ni K9l5Rlslmu85fmAQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 2B3442C141; Mon, 17 Apr 2023 06:38:23 +0000 (UTC) Date: Mon, 17 Apr 2023 06:38:22 +0000 (UTC) From: Richard Biener To: Hans-Peter Nilsson cc: Richard Sandiford , =?GB2312?B?1tO+09Xc?= , "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.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 Fri, 14 Apr 2023, Hans-Peter Nilsson wrote: > 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). But it gets us in the "wrong" direction with the goal of having pluggable targets (aka a multi-target compiler)? Anyway, I suggest we'll see how the space requirements work out. We should definitely try hard to put the fields on a byte boundary so accesses become at most a load + and. Richard.