This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is there a way to tell gcc to allocate local variable on the heap not the default stack?


>No, there is no option for that.  (In C++, you can have objects that
>manage data on the heap so that the object itself is local on the stack
>but the bulk of the storage is on the heap.)

>There are some warning options that could help you spot problem
>functions, like -Wlarger-than and -Wstack-usage.  You can also generate
>stack usage information with -fstack-usage.

>Also note that if the objects are not VLAs and you are not using
>recursion, you can usually use "static" on the local variables to give
>them fixed static addresses (in the data/bss section, rather than the
>heap or stack) and thus move them off the stack.

>Finally, are you sure the stack usage is actually a problem?

Thanks a lot David :)

Since I want to migrate many synchronous codes (currently) into
asynchronous implementation by hooking the blocking syscalls for
concurrency and performance by using C coroutine (copy stack). The
split-stack is fine but it is not mature in GCC (from aspects of
performance and customizability). And the standalone stack for each
coroutine would also cost too much.

(The -Wlarger-than, -Wstack-usage and -fstack-usage is very great and I'm
using it.)

(Sorry for reposting)

On Wed, May 30, 2018 at 8:31 AM, Remus Clearwater <
remus.clearwater@gmail.com> wrote:

> >No, there is no option for that.  (In C++, you can have objects that
> >manage data on the heap so that the object itself is local on the stack
> >but the bulk of the storage is on the heap.)
>
> >There are some warning options that could help you spot problem
> >functions, like -Wlarger-than and -Wstack-usage.  You can also generate
> >stack usage information with -fstack-usage.
>
> >Also note that if the objects are not VLAs and you are not using
> >recursion, you can usually use "static" on the local variables to give
> >them fixed static addresses (in the data/bss section, rather than the
> >heap or stack) and thus move them off the stack.
>
> >Finally, are you sure the stack usage is actually a problem?
>
> Thanks a lot David :)
>
> Since I want to migrate many synchronous codes (currently) into
> asynchronous implementation by hooking the blocking syscalls for
> concurrency and performance by using C coroutine (copy stack). The
> split-stack is fine but it is not mature in GCC (from aspects of
> performance and customizability). And the standalone stack for each
> coroutine would also cost too much.
>
> (The -Wlarger-than, -Wstack-usage and -fstack-usage is very great and I'm
> using it.)
>
> On Tue, May 29, 2018 at 2:36 PM, David Brown <david@westcontrol.com>
> wrote:
>
>> On 29/05/18 03:27, Remus Clearwater wrote:
>> > Hi, for some reason, I want to keep the stack frame usage of some
>> functions
>> > as smaller as possible, but rewrite them by hands is such a pain and
>> very
>> > stupid since they are using many and big local variables currently. And
>> in
>> > these functions they doesn't do anything like longjmp.
>> >
>> > So, is there a option to tell gcc to allocate local variable on the heap
>> > not the default stack (auto free them before return)?
>> >
>>
>> No, there is no option for that.  (In C++, you can have objects that
>> manage data on the heap so that the object itself is local on the stack
>> but the bulk of the storage is on the heap.)
>>
>> There are some warning options that could help you spot problem
>> functions, like -Wlarger-than and -Wstack-usage.  You can also generate
>> stack usage information with -fstack-usage.
>>
>> Also note that if the objects are not VLAs and you are not using
>> recursion, you can usually use "static" on the local variables to give
>> them fixed static addresses (in the data/bss section, rather than the
>> heap or stack) and thus move them off the stack.
>>
>> Finally, are you sure the stack usage is actually a problem?
>>
>>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]