Re: GCC stack size
Re: GCC stack size
- Subject: Re: GCC stack size
- From: Ryan McGann <email@hidden>
- Date: Wed, 04 Mar 2009 01:48:31 -0800
On Mar 3, 2009, at 2:00 PM, Brian Mastenbrook wrote:
On Mar 3, 2009, at 3:35 PM, Ryan McGann wrote:
We have some sample code that shows that the temporary returned
from the function doMath is allocated stack space twice, when it
can only be used once. But since the function in our actual
production code is pretty complex, it's hard to know hwich problem
we are experiencing.
However, the above examples are both well documented cases of GCC
problems; I actually got the basic ideas for both examples from
Linus Torvald's (sometimes long) emails regarding Linux's problems
with GCC stack allocation.
I've been bitten by this problem in the past as well, especially in
functions that look a lot like the examples you've given (where an
outer if wraps several complex code blocks). The worst of it is that
in this example:
Yes, it looks like we are running into that problem. We don't have any
large structures allocated on the stack, but a couple of ints here and
there start to add up.
In addition, it seems like GCC handles temporaries equally poorly. We
have some code blocks that are very deeply nested due to switch
statements and if/else blocks, and gcc seems to not know that certain
temporaries it created for statements in the if condition can go away
once the if statement has been evaluated.
We have a lot of code that looks like:
switch(something)
{
case blah:
{
if ((scanner->get_offset() + buffer_manager->get_offset() +
scanner->start()) < cur_offset)
{
}
} break;
}
GCC does all the math using temporaries, and then never realizes that
the stack space for the temporaries can be re-used once the if
statement has been evaluated. I tried turning off inlining--all those
get() functions above are one line functions implemented in the header
file, so gcc inlines them--but that seems to make little difference,
which makes sense since all those "functions" are not really doing
anything.
There are still a few options left to you that I can think of. The
first is to use LLVM - but in a slightly different way. Try running
the code through llvm-gcc with the C backend, and fiddling with the
different LLVM optimization settings. It's possible that llvm's
better analysis of local variable liveness will result in (mangled
and unreadable) C output that doesn't demonstrate the problem.
Interesting. From the --help for llvm-gcc-4.2 I can't make much sense
of it, or at least how to specify the output type. Whenever I tired it
it seemed to just call gcc, but I'll have to play with it more. But
since our library (and this function) is C++ not sure I can use this
option anyway.
Another option would be to hack up a transformer using clang
(assuming your code is pure C), which would perform directed partial
outlining on the functions you've identified to be problematic.
Alas the code is C++. It's not *really* C++, as it doesn't even use
virtual functions--it's more like structs with operator new()
overriden to use lookaside lists, but still not pure C.
Thanks,
Ryan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden