From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5084 invoked by alias); 20 Feb 2006 22:52:43 -0000 Received: (qmail 5064 invoked by alias); 20 Feb 2006 22:52:41 -0000 Date: Mon, 20 Feb 2006 22:52:00 -0000 Message-ID: <20060220225241.5063.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/26388] Variable sized storage allocation should be promoted to stack allocation In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenther at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-02/txt/msg02355.txt.bz2 List-Id: ------- Comment #5 from rguenther at suse dot de 2006-02-20 22:52 ------- Subject: Re: Variable sized storage allocation should be promoted to stack allocation > ------- Comment #4 from falk at debian dot org 2006-02-20 22:35 ------- > This would be incredibly difficult to detect reliably. But the main > problem is, on most operating systems, stack space is limited, > typically to something tiny compared to main memory like 8M, so this > wouldn't really be a good idea. Anyway, due to the amortization, I > suspect it wouldn't save all that much time. Have you tried some > benchmarks? No I didn't do benchmarks. But doing a lot of computation using libstdc++ containers takes a quite amount of time for tramp3d benchmark if using the new allocator (operator new (unsigned int) is on top of the profile for small array sizes), while it improves by using the mt allocator (mainly due to less overhead and better cache locality with using the size-pools). Looking at the affected algorithms they all collect information in vectors, do some processing and then throw the vector away again. Of course this could all be addressed at the algorithmic level by just not using libstdc++ containers but local stack arrays - just using libstdc++ is more expressive for this kind of stuff. If this is really not feasible or will not work in any useful cases, maybe exposing the stack to the user would be a nice thing to have. Like foo() { int *p = __builtin_stack_top(); *(p--) = i; ... } where __builtin_stack_top() would be beyond the known stack usage of foo(), erroring in case of function calls, of course (or even make the stack decrements builtins). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388