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 A10453858C52 for ; Mon, 10 Apr 2023 15:10:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A10453858C52 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=1681139456; 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:in-reply-to:in-reply-to: references:references; bh=8SEuATsyD5RmpHdfcxb7XFTI1ALMyIT2QzpofYv6Nhs=; b=SrDL0T31zDJGyR2qgSwo/KDM0/oloDvXo5BPzL/5JPZ4LUoDKOcEnJa7+bBuSzkL4SanuQ RRcghS+epVGRRcXC1A0403SnE5DKO5MgF5Oz27ZOE4zO8KJbZM8SPw+/UXjStbVueyaGle cHGxZd8XDgxgb0aImRGWZ3uT6a3UKfU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-569-4Jl2oaXLOZOZwnnQ50vL-g-1; Mon, 10 Apr 2023 11:10:50 -0400 X-MC-Unique: 4Jl2oaXLOZOZwnnQ50vL-g-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5EB5C811E7C; Mon, 10 Apr 2023 15:10:50 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0FC8FC15BA0; Mon, 10 Apr 2023 15:10:49 +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 33AFAkNh2460488 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 10 Apr 2023 17:10:46 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 33AFAiRM2460487; Mon, 10 Apr 2023 17:10:44 +0200 Date: Mon, 10 Apr 2023 17:10:44 +0200 From: Jakub Jelinek To: juzhe.zhong@rivai.ai Cc: gcc-patches@gcc.gnu.org, kito.cheng@gmail.com, palmer@dabbelt.com, jeffreyalaw@gmail.com, richard.sandiford@arm.com, rguenther@suse.de Subject: 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> MIME-Version: 1.0 In-Reply-To: <20230410144808.324346-1-juzhe.zhong@rivai.ai> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.3 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 10:48:08PM +0800, juzhe.zhong@rivai.ai wrote: > * rtl.h (struct GTY): Ditto. > --- a/gcc/rtl.h > +++ b/gcc/rtl.h > @@ -313,7 +313,7 @@ struct GTY((desc("0"), tag("0"), > ENUM_BITFIELD(rtx_code) code: 16; > > /* The kind of value the expression has. */ > - ENUM_BITFIELD(machine_mode) mode : 8; > + ENUM_BITFIELD(machine_mode) mode : 16; > > /* 1 in a MEM if we should keep the alias set for this mem unchanged > when we access a component. At least for struct rtx_def this is certainly unacceptable. The widely used structure is carefully laid out so that it doesn't waste any bits - there are 16 + 8 + 8 bits, then 32-bit union, and then union of something that needs on 64-bit hosts 64-bit alignment. So header nicely 64 bits before the variable sized payloads. The above change grows that to 16 + 16 + 8 bits, the 32-bit union needs 32-bit alignment, so that is already 96 bits, and then the payload which needs 64-bit alignment, so the above change grows the rtl header by 100%, from 64-bits to 128-bits. > --- a/gcc/tree-core.h > +++ b/gcc/tree-core.h > @@ -1693,7 +1693,7 @@ struct GTY(()) tree_type_common { > unsigned restrict_flag : 1; > unsigned contains_placeholder_bits : 2; > > - ENUM_BITFIELD(machine_mode) mode : 8; > + ENUM_BITFIELD(machine_mode) mode : 16; > > /* TYPE_STRING_FLAG for INTEGER_TYPE and ARRAY_TYPE. > TYPE_CXX_ODR_P for RECORD_TYPE and UNION_TYPE. */ This structure has 15 spare bits, so in theory it could be accomodated to handle more bits for mode, but the above change is insufficient for that. > @@ -1776,7 +1776,7 @@ struct GTY(()) tree_decl_common { > struct tree_decl_minimal common; > tree size; > > - ENUM_BITFIELD(machine_mode) mode : 8; > + ENUM_BITFIELD(machine_mode) mode : 16; > > unsigned nonlocal_flag : 1; > unsigned virtual_flag : 1; I think this one has 13 spare bits, but again one would need to adjust the structure more so that it doesn't grow unnecessarily. I think you should try hard to avoid having too many modes, there are a lot of arrays especially in RA sized by number of modes or even that times number of register classes (I thought we have some number of modes ^ 2 but can't find them right now), and if there is no way to avoid that, we should consider making those changes dependent on maximum number of modes and use current more compact compile time memory data structures unless the target has more than 256 modes. Jakub