This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inlining vs the stack
Mike Stump <mrs@apple.com> writes:
> In general you'll want to understand how OSes allocate stack, and how
> the determine if an access is to the stack or not. The canonical
> unix way is to catch a fault, and if that fault is within X MB (8MB
> in years past) of the top of the stack, assume that the access is
> meant for the stack, extend it, and then retry the instruction. If
> the access is X+1 MB away, the program dies a horrible death. This
> line is arbitrary, exists, and is the difference between a running
> application and one that dies.
Yes.
> Any transformation that increases the stack size from X to X + 1 is
> an invalid transformation. Currently, inlining can do this, and it
> is wrong. X can be run time selectable, OMF selectable, OS defined...
No.
Making the stack bigger by inlining is no different from making it
bigger by declaring and using more local variables or calls to alloca.
If the compiler can't handle a large stack, that is a bug in the
compiler. In particular, see the allocate_stack instruction pattern.
Ian