[LLVMdev] Explicitly Managed Stack Frames
sabre at nondot.org
Sat Jan 14 13:05:03 PST 2006
On Sat, 14 Jan 2006, Ben Chambers wrote:
> Chris Lattner wrote:
>> On Wed, 11 Jan 2006, Ben Chambers wrote:
>>> I was wondering what the current state of this (explicitly managed stack
>>> is. Is it being worked on? If not, how hard do you think it would be for
>>> me to
>>> add it?
>> I'm not sure what you mean. It depends on correct tail calls, but no other
>> LLVM-level support.
> Really? But if there are explicitly managed stack frames, it would be best
> for LLVM to spill registers into that location. Otherwise, the front-end
> will be generating code to store the variable into the explicit stack frame
> before performing a call, and LLVM may emit some spill code to load that
> variable off the real stack frame (the one that LLVM uses).
Really really. The point of converting to CPS style and using tail calls
is so that the code generator can use the local stack for spills without
getting into trouble.
> So it seems like it is pretty easy to make code that will work, but at
> the same time I think it will either prevent or make less useful a good
> portion of the optimization work that has gone into LLVM. I guess the
> only way to know for sure is to implement it... so I'll get started on
> that :P
>> Ok. Are you planning on garbage collecting your stack frames, or do you
>> just need a static link? If you just need a static link (because of nested
>> functions like pascal) but don't need GC'd stack frames, there is no need
>> even for tail call support and CPS and other craziness, just pass your
>> static link or display as an argument: lower to LLVM just like you would
>> lower to machine code.
> In order to return closures (which are functions, but may have some
> dependence on the environment in which they are created), you need to keep
> all the preceeding stack frames alive until after the closure goes dead. The
> easiest way to implement this, by far, is through the use of garbage
> collected stack frames. It also results in the highest efficiency.
Yup, makes sense!
More information about the llvm-dev