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

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

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carrot at google dot com

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-07-27 10:56:13 UTC ---
*** Bug 43513 has been marked as a duplicate of this bug. ***

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

[xiaoyuanbo at yeah dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388

xiaoyuanbo <xiaoyuanbo at yeah dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xiaoyuanbo at yeah dot net

--- Comment #9 from xiaoyuanbo <xiaoyuanbo at yeah dot net> 2012-02-22 12:43:25 UTC ---
and you call manager remove it

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

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-02-21 02:22 -------
I am going to say there are better ways of optimizing this than using the
stack.
the easy way to optimize this in your code is to reserve the required size
before the loop, this is done in GCC also with the VEC already..


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388

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

[falk at debian dot org]

------- Comment #6 from falk at debian dot org  2006-02-20 23:06 -------
(In reply to comment #5)

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

This would be a quite finicky interface. For example, on the Alpha
architecture,
the stack pointer needs to be 16-byte aligned at all times. Also, you must
not read at some position on the stack unless you've previously written within
4096 bytes (or something) of that position. I suppose other architectures
have similar peculiarities.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388

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

[rguenther at suse dot de]

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

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

[falk at debian dot org]

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388

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

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2006-02-20 22:34 -------
make it return the largest prime, factors[factors.size()-1] instead.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388

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

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2006-02-20 22:27 -------
Ok, here's a real example:

template <typename T>
std::vector<T> makeRBlocksFactor(T number)
{
  std::vector<T> factors;

  for (T f=2; f<number; f++) {
    while (number % f == 0) {
      factors.push_back(f);
      number /= f;
    }
  }
  if (number != 1)
    factors.push_back(number);
  return factors;
}

stupid way of calculating prime factors of number.  Of course here we have
NRV optimization (maybe).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388

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

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-20 22:21 -------
Actually this is all dead code and should be removed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388