similar to: [LLVMdev] [Segmented Stacks] Week 1

On 11-06-02 07:47 PM, Peter Lawrence wrote: > Guys, > regarding alloca. > > not only are exceptions a problem here, but just plain old "longjmp". Yes, On IRC Sanjoy pointed out that it should be possible to handle this by changing longjmp. I am not sure it can be done in general. The alloca might have been called a dynamic number of times for example. In fact, now that I

On 11-05-30 07:20 AM, Sanjoy Das wrote: > 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). Thanks!. Some quick notes *) Maybe you

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

Sorry for the delay in responding. On Mon, 13 Jun 2011, Rafael Avila de Espindola wrote: > On 11-06-02 07:47 PM, Peter Lawrence wrote: >> Guys, >> regarding alloca. >> >> not only are exceptions a problem here, but just plain old "longjmp". > > Yes, > On IRC Sanjoy pointed out that it should be possible to handle this by > changing longjmp. I am

On Thu, Jun 23, 2011 at 03:21:58PM -0400, Brian Hurt wrote: > Segmented stacks are exciting to me, but only if the stacklets can be > freed. Here's why: if segmented stacks allow for "infinite" stacks, tail > call optimization becomes a lot less important in functional languages- > still useful, but not live or die. We discussed this on IRC a while ago. IMHO it is

Hi llvmdev! I've been working on implementing support for segmented stacks in LLVM (towards GSoC '11). Currently I'm working on adding intrinsics for coroutines. The problem is this: Till now I had been depending on libgcc for runtime support (and was being 100% libgcc compatible in the process). However, since all the stack allocation routines in libgcc depend on TLS variables to

On Thu, 23 Jun 2011, Joerg Sonnenberger wrote: > On Thu, Jun 23, 2011 at 03:21:58PM -0400, Brian Hurt wrote: >> Segmented stacks are exciting to me, but only if the stacklets can be >> freed. Here's why: if segmented stacks allow for "infinite" stacks, tail >> call optimization becomes a lot less important in functional languages- >> still useful, but not

On 08/10/2011 11:03 AM, Sanjoy Das wrote: > Hi! > > Attached my pre-midterm GSoC work for segmented stacks for review (with > the required fixes). Nice work! + extern bool EnableSegmentedStacks; Can you add a comment like the other declarations? I think the patch looks good. There are possible improvements, but the patch is already in an state where it can be tested and extended

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, > I've been working on implementing support for segmented stacks in LLVM > (towards GSoC '11). Currently I'm working on adding intrinsics for > coroutines. The problem is this: > > Till now I had been depending on libgcc for runtime support (and was > being 100% libgcc compatible in the process). However, since all the > stack allocation routines in

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 07/28/2011 05:31 PM, Sanjoy Das wrote: > Hi llvmdev! > > I've been working on adding coroutines to LLVM. Mentioned below is the > implementation plan I'm following, for suggestions, flames and other > input. Using segmented stacks is a prerequisite. I think my only comment is that, while this would probably work, implementing it in C with a bit of assembly for

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 llvmdev! I've been working on adding coroutines to LLVM. Mentioned below is the implementation plan I'm following, for suggestions, flames and other input. Using segmented stacks is a prerequisite. The idea is to associate every coroutine with a coroutine descriptor. A coroutine descriptor consists of four words: w0, w1, w2 and w3. w0 always contains the _launcher_, and invoking a

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

On Thu, Jul 14, 2011 at 9:07 AM, Sanjoy Das <sanjoy at playingwithpointers.com>wrote: > 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

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! > 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

Hi! First of all, sorry for the delay. This about fixing the issue with having a the BB ending with a non-terminating instruction when compiling with segmented stacks. I'm not sure if having an isel pseudo instruction which is lowered into a RET and then a MOV would work better. LLVMTargetMachine::addCommonCodeGenPasses adds the ExpandISelPseudosPass before the PEI pass (so it boils down to

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