From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 435F43858298 for ; Fri, 10 Mar 2023 10:37:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 435F43858298 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 63061C14; Fri, 10 Mar 2023 02:38:28 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 305233F5A1; Fri, 10 Mar 2023 02:37:44 -0800 (PST) From: Richard Sandiford To: Bernhard Reutner-Fischer via Gcc-patches Mail-Followup-To: Bernhard Reutner-Fischer via Gcc-patches ,juzhe.zhong@rivai.ai, Bernhard Reutner-Fischer , kito.cheng@gmail.com, richard.sandiford@arm.com Cc: juzhe.zhong@rivai.ai, Bernhard Reutner-Fischer , kito.cheng@gmail.com Subject: Re: [PATCH] RISC-V: Add fault first load C/C++ support References: <20230307062123.142975-1-juzhe.zhong@rivai.ai> <9A4FC141-459E-414B-BBA0-07D3275BCFFA@gmail.com> Date: Fri, 10 Mar 2023 10:37:42 +0000 In-Reply-To: <9A4FC141-459E-414B-BBA0-07D3275BCFFA@gmail.com> (Bernhard Reutner-Fischer via Gcc-patches's message of "Wed, 08 Mar 2023 22:16:59 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-27.5 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Bernhard Reutner-Fischer via Gcc-patches writes: > On 7 March 2023 07:21:23 CET, juzhe.zhong@rivai.ai wrote: >>From: Ju-Zhe Zhong >> > >>+class vleff : public function_base >>+{ >>+public: >>+ unsigned int call_properties (const function_instance &) const override >>+ { >>+ return CP_READ_MEMORY | CP_WRITE_CSR; >>+ } >>+ >>+ gimple *fold (gimple_folder &f) const override >>+ { >>+ /* fold vleff (const *base, size_t *new_vl, size_t vl) >>+ >>+ ====> vleff (const *base, size_t vl) >>+ new_vl = MEM_REF[read_vl ()]. */ >>+ >>+ auto_vec vargs; > > Where is that magic 8 coming from? I'm probably not saying anything you don't already know, but: The second template parameter is just an optimisation. It reserves a "small" amount of stack space for the vector, to reduce the likelihood that a full malloc/free will be needed. The vector can still grow arbitrarily large. So these numbers are always just gut instinct for what a reasonable common case would be. There's no particular science to it, and no particular need to explain away the value. The second parameter is still useful if the vector size is known at construction time. When I've looked at cc1 and cc1plus profiles in the past, malloc has often been a significant contributor. Trying to avoid malloc/free cycles for "petty" arrays seems like a worthwhile thing to do. Thanks, Richard