From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 707E33858D38 for ; Tue, 11 Apr 2023 09:16:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 707E33858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681204571; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jYY4jjD1dguusSHWCpg2gmCAUqIlYz0g9wQsePYutDM=; b=dhj3J+HL4TrzI4iy9MDTHAqkOtjbobDl0AoATa11zX3v0fAkd5p5N4ZjUu1iCG1dSAel4Z J/0inbXrEjPc3c8PvTk7KX2nU+IL7k3Rg/oxufk5+EJVNTdS2g6AIsuFt1S2H+2aITc4f/ nUC8mc+RVOvxYsl+lNUedlnH6gZknBU= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-213-UmIADzqjNOmcyZYtYHlIgg-1; Tue, 11 Apr 2023 05:16:07 -0400 X-MC-Unique: UmIADzqjNOmcyZYtYHlIgg-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 271383C10EC3; Tue, 11 Apr 2023 09:16:07 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D84FE492B01; Tue, 11 Apr 2023 09:16:06 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 33B9G35m2466071 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 11 Apr 2023 11:16:03 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 33B9G1fQ2466070; Tue, 11 Apr 2023 11:16:01 +0200 Date: Tue, 11 Apr 2023 11:16:00 +0200 From: Jakub Jelinek To: juzhe.zhong@rivai.ai Cc: Jeff Law , gcc-patches , "kito.cheng" , palmer , "richard.sandiford" , rguenther Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit Message-ID: Reply-To: Jakub Jelinek References: <20230410144808.324346-1-juzhe.zhong@rivai.ai> <89f088ec-8692-01f5-0395-5a66ddf085d7@gmail.com> <47D962C7C724E3A2+20230410231445834316202@rivai.ai> MIME-Version: 1.0 In-Reply-To: <47D962C7C724E3A2+20230410231445834316202@rivai.ai> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP 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 Mon, Apr 10, 2023 at 11:14:46PM +0800, juzhe.zhong@rivai.ai wrote: > ARM SVE has：svint8_t, svint8x2_t, svint8x3_t, svint8x4_t > As far as I known, they don't have tuple type for partial vector. > However, for RVV not only has vint8m1_t, vint8m1x2_t, vint8m1x3_t, > vint8m1x4_t, vint8m1x5_t, vint8m1x6_t, vint8m1x7_t, vint8m1x8_t > > But also, we have vint8mf8_t, vint8mf8x2_t, vint8mf8x3_t, > vint8mf8x4_t, vint8mf8x5_t, vint8mf8x6_t, vint8mf8x7_t, vint8mf8x8_t > > vint8mf4_t, vint8mf4x2_t, vint8mf4x3_t, > vint8mf4x4_t, vint8mf4x5_t, vint8mf4x6_t, vint8mf4x7_t, vint8mf4x8_t > > ....etc > > So many tuple types. Do all of them need their own mode? I mean, can't you instead use say some backend aggregate types which act like homogenous aggregates in various backends? Modes are needed for something that can appear in instructions, for something that can be lowered say during expansion at latest you don't need special modes. I admit I don't know much about RVV, but if those tuples are to be handled as configure the CPU for certain vector length, perform some instruction on effectively variable length vector with certain element and then reconfigure the CPU again for something else, couldn't the only vector modes there be the variable length ones? Jakub