Re: GCC stack size
Re: GCC stack size
- Subject: Re: GCC stack size
- From: Eric Gouriou <email@hidden>
- Date: Fri, 20 Feb 2009 22:07:54 -0800
On Feb 20, 2009, at 4:15 PM, Ryan McGann wrote:
A couple weeks ago I asked about a machine-check panic I was
getting. As it turns out, my suspicions were right about stack
corruption. I disassembled a function in our kext and saw that for
some reason, GCC's function prologue was allocating around 1660
bytes of stack (in release, debug was slightly better at 1140
bytes). On other platforms compiled with GCC (FreeBSD and many
different Linux distros) the stack usage is near 110 bytes, but for
some reason gcc on Mac OS X is allocating almost 4K.
We are currently using -O3 because the code is pretty compute-bound,
and on other platforms -O3 has a nice 5% boost compared to -O2. But
changing it to -O2 doesn't even help, we have to go all the way to -
O1 to get a usable stack of 400 bytes (still 4x larger than our
Linux driver).
What are your compile options, besides -O3 ?
Do you have the same issue when using -mkernel -Os ?
(-Os on Apple's gcc is mostly -O2 with a bit more emphasis on code size)
The code is vanilla C++ without anything fancy—no virtual functions
even. There are no warnings about temporarys being used, so I have
no clue what is causing the stack usage. It's a huge function with a
lot ofswitch statements and for loops, but not a lot of function
calls, mostly just computes on arrays of data. My best guess is that
GCC is trying to optimize the intermediate operations and temporary
results by placing them on the stack.
You say "not a lot of function calls". Can you disable inlining or
throttle it down to check
that it's not the cause of the bloat ? If so, -Os would help.
Eric
Anybody have ideas on how to show where GCC is allocating things in
the frame, and how to reduce the stack usage? It's hard to distill
this to a single issue because the function is so large, but I am
tempted to file a bug since GCC 4 optimizes things quite nicely on
other platforms.
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
_______________________________________________
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