[Bug tree-optimization/26388] Variable sized storage allocation should be promoted to stack allocation

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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