From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 1A8923858D32 for ; Tue, 28 Feb 2023 02:47:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1A8923858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 9D7DB1E128; Mon, 27 Feb 2023 21:47:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1677552476; bh=7bvqhpKEL5jUa00Rwoyen6WJIpMsXTFfAc1v3IDPF+A=; h=Date:Subject:To:References:From:In-Reply-To:From; b=rz0FDTy+HgXuyKPMWDxF6UBQN1BY/8cgmlB3PCdwBJnfb44bhIPVGB5H7XSZSZIs6 NSYbhfI6kBBhyCgeaPvbYzD4JLX8/aPgk13+0p64h1oCbzlyYtvQjmJLN/1gERpVQg pKZfC6RmkfrnnbuYt6hax2k5yl6N6N998u5rP84U= Message-ID: Date: Mon, 27 Feb 2023 21:47:55 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 00/13] Remove a bunch of alloca uses Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,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 2/27/23 16:29, Andrew Burgess via Gdb-patches wrote: > Continuing effort to replace alloca calls with C++ data structures, > here's a bunch of places where gdb::byte_vector can be used. > > This isn't all of them, there's still plenty to work through, but I > thought I'd see how this lot is received. Every time I spot an alloca in the wild, I'm also tempted to switch it to vector or something like that. But then I think, it's an extra dynamic allocation for no real gain, so it would just make things worse. When we know the maximum size a buffer can have, instead of using alloca, it would better to statically allocate that size on the stack, and then user an array_view to define the effectively used portion of it. For the cases where we don't (I'm thinking of buffer the size of registers, often small, but there isn't a statically known maximum length), perhaps an std::vector-like structure with small size optimization (like std::string has) would be nice. So you could define a buffer that would use stack memory up to let's say 128 bytes, and heap memory above that. Some references: https://stoyannk.wordpress.com/2017/11/18/small-vector-optimization/ https://llvm.org/doxygen/classllvm_1_1SmallVector.html https://github.com/facebook/folly/blob/main/folly/docs/small_vector.md https://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.html With something like this, I think we could change pretty much all allocas without feeling bad about it. If the license allows, I'd be all for just importing an existing implementation in our code base, to avoid reinventing the wheel. Simon