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 564203858C31 for ; Mon, 2 Oct 2023 07:12:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 564203858C31 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=1696230770; 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=ah+DQBBa36CLL3Z+1QguX6RER6gyp/8e7K6KdUNL6u4=; b=P+HjF4w4PeqzHhRi8OOjiRSS7K2V5JE8XI9Nld5niR5DDGcpnxLKN7JVffIPWrD/tb6cna PacPrxHGeNij1KDGzSDO3D+4ocSIztRXr0k5ZssrGZJZ0uFuPjqN92seTqjxSxG5+3Nzk1 o4JlZ4kZpz8jSFFor3drWZjsTGq8mhs= Received: from mimecast-mx02.redhat.com (mx-ext.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-225-SGzbtGJAPE6gyicX24GySQ-1; Mon, 02 Oct 2023 03:12:43 -0400 X-MC-Unique: SGzbtGJAPE6gyicX24GySQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4345C29AB3F9; Mon, 2 Oct 2023 07:12:43 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.202]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 04758C15BB8; Mon, 2 Oct 2023 07:12:42 +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 3927CeCi3530428 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 2 Oct 2023 09:12:40 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 3927CdEL3530427; Mon, 2 Oct 2023 09:12:39 +0200 Date: Mon, 2 Oct 2023 09:12:38 +0200 From: Jakub Jelinek To: =?utf-8?B?6ZKf5bGF5ZOy?= , Jeff Law Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] RISC-V: Use safe_grow_cleared for vector info [PR111469] Message-ID: Reply-To: Jakub Jelinek References: <20230930230019.865326-1-patrick@rivosinc.com> <20DBB04A235265AE+202310010703506641526@rivai.ai> MIME-Version: 1.0 In-Reply-To: <20DBB04A235265AE+202310010703506641526@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,RCVD_IN_SBL_CSS,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 Sun, Oct 01, 2023 at 07:03:51AM +0800, 钟居哲 wrote: > LGTM. > > juzhe.zhong@rivai.ai > > diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc > index af8c31d873c..4b06d93e7f9 100644 > --- a/gcc/config/riscv/riscv-vsetvl.cc > +++ b/gcc/config/riscv/riscv-vsetvl.cc > @@ -2417,8 +2417,8 @@ vector_infos_manager::vector_infos_manager () > vector_antin = nullptr; > vector_antout = nullptr; > vector_earliest = nullptr; > - vector_insn_infos.safe_grow (get_max_uid ()); > - vector_block_infos.safe_grow (last_basic_block_for_fn (cfun)); > + vector_insn_infos.safe_grow_cleared (get_max_uid ()); > + vector_block_infos.safe_grow_cleared (last_basic_block_for_fn (cfun)); > if (!optimize) > { > basic_block cfg_bb; Note, while it works around the build failure, I strongly doubt it is the right fix in this case. The other spots which have been changed similarly are quite different, all the vec cases have been followed (almost) immediately by bitmap_initialize of all the elements or just 1-3 elements and their actual uses. The above is very different. Sizing a vector with get_max_uid () means it is very likely very sparse and so constructing every element in the array seems undesirable. While it is true that e.g. IRA or DF use vectors indexed by INSN_UID, I think the vectors pretty much always have pointer elements and say pool allocate what it points to upon first access. While vector_insn_info is huge (48 bytes on 64-bit hosts from what I can see) even without much attempts to make it shorter (e.g. the vl_vtype_info member ordering of 2xpointer sized member, 1 byte member, 4 byte member, 3 1 byte members creates unnecessary padding). The reason why arrays indexed by INSN_UID are sparse are 3: 1) we have --param min-nondebug-insn-uid= parameter (where, albeit usually just for debugging, one can specify very high start for those, say --param min-nondebug-insn-uid=100000 means debug insns will be created with INSN_UID 1 and up, while non-DEBUG_INSNs only with INSN_UID 100000 and up, so even a function containing just 3-4 insns will have get_max_uid () of 100004 or so; the above allocates in that case 100004 * 48 bytes (bad) and newly constructs all the elements in it 2) INSN_UIDs are given to all newly created insns during RTL optimizations, when an insn is deleted, its INSN_UID is not reused, so there can be large gaps; the more churn in RTL optimizations, the larger 3) INSN_UIDs are given even to BARRIERs, DEBUG_INSNs etc., plus the question is if the algorithm really needs to track every "normal" insn as well, whether it shouldn't track just those that are in some ways using vectors or relevant to it, many scalar instructions might be uninteresting, DEBUG_INSNs certainly should be uninteresting (they must not affect code generation), etc. So, I think having something lazily allocated and initialized on demand might be a compile time memory and time win. For basic blockswe perform some block number compactions during compilation, so those shouldn't be denser. But the structure for each basic block is even bigger (104 bytes, because it contains 2 x 48 plus probability). E.g. DF uses for many purposes LUIDs instead, which need to be recomputed, but are logical uids within each basic block. Jakub