[LLVMdev] RFC: GSoC Project

[Talin]

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.

On Wed, Mar 23, 2011 at 3:07 AM, Sanjoy Das
<sanjoy at playingwithpointers.com>wrote:

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



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110410/d41e8877/attachment.html>