I wonder - would something like this allow for multiple stacks for a single thread? I'm thinking of something like continuations / fibers / green threads, which would be very handy.<br><br><div class="gmail_quote">On Wed, Mar 23, 2011 at 3:07 AM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi All!<br>
<br>
I will be applying to the LLVM project for this GSoC, and I wanted some<br>
preliminary sanity check on my project idea.<br>
<br>
I intend to implement split (segmented) stacks for LLVM (like we have in<br>
Go, and as being implemented for GCC [1]). A lot of what follows is<br>
lifted from [1]; I will progressively add more details as I get more<br>
familiar with the LLVM codebase.<br>
<br>
I intend to start with the simplest possible approach - representing the<br>
stack as a doubly linked list of _block_s, the size of each _block_<br>
being a power of two. This can later be modified to improve performance<br>
and accommodate other factors. Blocks will be chained together into a<br>
doubly linked list structure (using the first two words in the block as<br>
the next and previous pointers).<br>
<br>
In the prologue, a function will check whether the current block has<br>
enough stack space. This is easily done for function which don't have<br>
variable sized allocas, and for ones which do, we can assume some<br>
worst-case upper bound. The prologue can then call an intrinsic (let's<br>
call it llvm.adjust_stack) which allocates a new block (possibly by<br>
delegating this to a user-provided callback), copies the arguments,<br>
saves the previous stack pointer (in the new block), and adjusts the<br>
next and previous pointers. It will also have to adjust the stack<br>
pointer, and the frame pointer, if it is being maintained. Cleanup can<br>
be done by hijacking the return value, as also mentioned in [1]. It<br>
might make sense to leave the allocated blocks around, to prevent<br>
re-allocating the next time the program needs more stack space.<br>
<br>
DWARF info can be generated as follows: since we know the offset of base<br>
of the stack frame from the stack pointer (or we are maintaining a frame<br>
pointer), we can always say whether the concerned call frame is the<br>
first call frame or not. In the second case, all the previous register<br>
values can be computed as usual, and in the first case, we will add an<br>
extra indirection, involving looking up the stack pointer saved in this<br>
block's header.<br>
<br>
One thing I'd really like some input on is whether implementing split<br>
stacks would be useful enough to warrant the effort (especially keeping<br>
in mind that this is pretty useless on 64 bit architectures).<br>
<br>
[1] <a href="http://gcc.gnu.org/wiki/SplitStacks" target="_blank">http://gcc.gnu.org/wiki/SplitStacks</a><br>
<font color="#888888">--<br>
Sanjoy Das<br>
<a href="http://playingwithpointers.com" target="_blank">http://playingwithpointers.com</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>