* [Bug tree-optimization/26388] Variable sized storage allocation should be promoted to stack allocation
2006-02-20 22:20 [Bug tree-optimization/26388] New: Variable sized storage allocation should be promoted to stack allocation rguenth at gcc dot gnu dot org
@ 2006-02-20 22:21 ` pinskia at gcc dot gnu dot org
2006-02-20 22:27 ` rguenth at gcc dot gnu dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-02-20 22:21 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/26388] Variable sized storage allocation should be promoted to stack allocation
2006-02-20 22:20 [Bug tree-optimization/26388] New: Variable sized storage allocation should be promoted to stack allocation rguenth at gcc dot gnu dot org
2006-02-20 22:21 ` [Bug tree-optimization/26388] " pinskia at gcc dot gnu dot org
@ 2006-02-20 22:27 ` rguenth at gcc dot gnu dot org
2006-02-20 22:34 ` rguenth at gcc dot gnu dot org
` (4 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2006-02-20 22:27 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/26388] Variable sized storage allocation should be promoted to stack allocation
2006-02-20 22:20 [Bug tree-optimization/26388] New: Variable sized storage allocation should be promoted to stack allocation rguenth at gcc dot gnu dot org
2006-02-20 22:21 ` [Bug tree-optimization/26388] " pinskia at gcc dot gnu dot org
2006-02-20 22:27 ` rguenth at gcc dot gnu dot org
@ 2006-02-20 22:34 ` rguenth at gcc dot gnu dot org
2006-02-20 22:36 ` falk at debian dot org
` (3 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2006-02-20 22:34 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/26388] Variable sized storage allocation should be promoted to stack allocation
2006-02-20 22:20 [Bug tree-optimization/26388] New: Variable sized storage allocation should be promoted to stack allocation rguenth at gcc dot gnu dot org
` (2 preceding siblings ...)
2006-02-20 22:34 ` rguenth at gcc dot gnu dot org
@ 2006-02-20 22:36 ` falk at debian dot org
2006-02-20 22:52 ` rguenther at suse dot de
` (2 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: falk at debian dot org @ 2006-02-20 22:36 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/26388] Variable sized storage allocation should be promoted to stack allocation
2006-02-20 22:20 [Bug tree-optimization/26388] New: Variable sized storage allocation should be promoted to stack allocation rguenth at gcc dot gnu dot org
` (3 preceding siblings ...)
2006-02-20 22:36 ` falk at debian dot org
@ 2006-02-20 22:52 ` rguenther at suse dot de
2006-02-20 23:06 ` falk at debian dot org
2006-02-21 2:22 ` pinskia at gcc dot gnu dot org
6 siblings, 0 replies; 10+ messages in thread
From: rguenther at suse dot de @ 2006-02-20 22:52 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/26388] Variable sized storage allocation should be promoted to stack allocation
2006-02-20 22:20 [Bug tree-optimization/26388] New: Variable sized storage allocation should be promoted to stack allocation rguenth at gcc dot gnu dot org
` (4 preceding siblings ...)
2006-02-20 22:52 ` rguenther at suse dot de
@ 2006-02-20 23:06 ` falk at debian dot org
2006-02-21 2:22 ` pinskia at gcc dot gnu dot org
6 siblings, 0 replies; 10+ messages in thread
From: falk at debian dot org @ 2006-02-20 23:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/26388] Variable sized storage allocation should be promoted to stack allocation
2006-02-20 22:20 [Bug tree-optimization/26388] New: Variable sized storage allocation should be promoted to stack allocation rguenth at gcc dot gnu dot org
` (5 preceding siblings ...)
2006-02-20 23:06 ` falk at debian dot org
@ 2006-02-21 2:22 ` pinskia at gcc dot gnu dot org
6 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-02-21 2:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 10+ messages in thread