similar to: [LLVMdev] GSoC '11: Segmented Stacks

Hi! Thanks for the feedback. For context, my implementation plan is here: http://pastebin.com/e9JMZNCE First, about unwinding: In architectures like x86-64, where unwinding based on DWARF info, there shouldn't be any problems; since the DWARF info will be emitted correctly. Otherwise, if the unwinding is done by following BP, it should still be possible to have BP de-reference correctly

On Mon, Apr 11, 2011 at 9:07 AM, Sanjoy Das <sanjoy at playingwithpointers.com>wrote: > Hi! > > Thanks for the feedback. For context, my implementation plan is here: > http://pastebin.com/e9JMZNCE > > First, about unwinding: > > In architectures like x86-64, where unwinding based on DWARF info, there > shouldn't be any problems; since the DWARF info will be

Hi! Thanks for the review. What follows is a revised version of the proposal. I'll post this on Melange after getting some more feedback. Segmented stacks for LLVM, GSoC '11 ----------------------------------- * Overview: Goal & Rationale Support segmented (split) stacks in LLVM. The idea is to allocate stack space to a thread incrementally, instead of allocating a (large)

On Sun, Apr 10, 2011 at 4:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Apr 10, 2011, at 2:45 PM, Talin wrote: > > 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. > > > I haven't looked at the proposal, but

This reminds me of Kenneth's "context" proposal from some time back: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-April/030787.html I haven't compared the two too closely, but I thought I should throw it out there as food for thought. Reid On Mon, Apr 11, 2011 at 3:26 PM, Talin <viridia at gmail.com> wrote: > On Mon, Apr 11, 2011 at 7:34 AM, Justin Holewinski >

On Mon, Apr 11, 2011 at 7:34 AM, Justin Holewinski < justin.holewinski at gmail.com> wrote: > On Mon, Apr 11, 2011 at 9:07 AM, Sanjoy Das < > sanjoy at playingwithpointers.com> wrote: > >> Hi! >> >> Thanks for the feedback. For context, my implementation plan is here: >> http://pastebin.com/e9JMZNCE >> >> First, about unwinding: >>

On Apr 10, 2011, at 2:45 PM, Talin wrote: > 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. I haven't looked at the proposal, but yes, this would be very useful functionality for LLVM to provide. -Chris > > On Wed, Mar 23, 2011 at 3:07 AM,

Hi! Attached my pre-midterm GSoC work for segmented stacks for review (with the required fixes). Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-New-command-line-option-to-enable-segmented-stacks.patch Type: text/x-diff Size: 1699 bytes Desc: not available URL:

Hi Sanjoy, The patch generally looks fine except for this part: diff --git a/lib/CodeGen/StackSegmenter.cpp b/lib/CodeGen/StackSegmenter.cpp new file mode 100644 index 0000000..5ffb8f2 --- /dev/null +++ b/lib/CodeGen/StackSegmenter.cpp @@ -0,0 +1,48 @@ +//===-- StackSegmenter.h - Prolog/Epilog code insertion -------*- C++ -* --===// The comment is obviously incorrect. diff --git

Hi llvm-dev! I have attached the current state of my GSoC work in patches [1] for review; this currently allows LLVM to correctly handle functions running out of stack space and variable sized stack objects. Firstly, since I think it is better to get things merged in small chunks, I'd like to have some specific feedback on where my work stands in terms of mergeability. Secondly, I had been

Hi! I've attached my first week of work as a patchset for review. This is also available on Github [1]. By next Monday I intend to (more or less) finish up the preliminary parts concerning the codegen; and start working on the runtime (so that I can do a basic sanity check). [1] https://github.com/sanjoy/llvm/tree/segmented-stacks -- Sanjoy Das http://playingwithpointers.com

Current set of patches for my work on segmented stacks. Go / dragonegg seems to work when using this code (I still haven't run any rigorous tests yet). Thanks! (Also on https://github.com/sanjoy/LLVM/tree/segmented-stacks) -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name:

On Wed, Mar 23, 2011 at 03:37:02PM +0530, Sanjoy Das wrote: > 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

Hi! > diff --git a/lib/CodeGen/StackSegmenter.cpp b/lib/CodeGen/StackSegmenter.cpp > new file mode 100644 > index 0000000..5ffb8f2 > --- /dev/null > +++ b/lib/CodeGen/StackSegmenter.cpp > @@ -0,0 +1,48 @@ > +//===-- StackSegmenter.h - Prolog/Epilog code insertion -------*- C++ -* --===// > > The comment is obviously incorrect. Thanks. So much for lifting file

On Aug 23, 2011, at 9:24 AM, Sanjoy Das wrote: > Hi! > >> diff --git a/lib/CodeGen/StackSegmenter.cpp b/lib/CodeGen/StackSegmenter.cpp >> new file mode 100644 >> index 0000000..5ffb8f2 >> --- /dev/null >> +++ b/lib/CodeGen/StackSegmenter.cpp >> @@ -0,0 +1,48 @@ >> +//===-- StackSegmenter.h - Prolog/Epilog code insertion -------*- C++ -* --===//

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

Hi all! Attached a three part series which implements the very first bits of my GSoC proposal (full proposal is here http://pastebin.com/e9JMZNCE), for some preliminary review. -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Adds-relevant-command-line-options.patch Type: text/x-diff Size: 2021 bytes Desc: not

Hi John & Ron, I read through the proposal and had a couple of quick observations. 1. The proposed encoding assumes that the epilogue instructions always come at the end of the function -- or rather, just before the next function. If there is a stack protector __stack_chk_fail sequence, or there is NOP padding between functions, then the epilogue cannot be expressed. The proposed encoding

Hi, attached is a second try for the bigstack patch for SPU, with testcase. It is essentially the patch committed as 97091, and reverted as 97099, but with the following additions: -in vararg handling, registers are marked to be live, to not confuse the register scavenger -function prologue and epilogue are not emitted, if the stack size is 16. 16 means it is empty - there is only the

Hi all! I've attached a corrected set of patches (based on the input I received here). Please let me know if this work looks mergeable. The documentation is only partially filled in, I'll add more details once support for Go is also merged (the current co-routine work I'm doing). Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A