similar to: [LLVMdev] Segmented Stacks: Pre-midterm work

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! I've been working on coroutines for some time, and it seems you were right - it makes much more sense to have regular C (and assembly) code for handling coroutines. For instance, I'd otherwise would have to make an assumption about the threading model the platform has (or assume there are no threads at all, which prevents me from allowing goroutine like ("run parallel till 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

Hi Sanjoy, > I've been working on coroutines for some time, and it seems you were > right - it makes much more sense to have regular C (and assembly) code > for handling coroutines. For instance, I'd otherwise would have to > make an assumption about the threading model the platform has (or > assume there are no threads at all, which prevents me from allowing > goroutine

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:

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! > 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! > According to the patch you send, the pass is not doing anything: > > +bool StackSegmenter::runOnMachineFunction(MachineFunction &MF) { > + return false; > +} > + It is, in the next patch. diff --git a/lib/CodeGen/StackSegmenter.cpp b/lib/CodeGen/StackSegmenter.cpp index 5ffb8f2..cc2ca87 100644 --- a/lib/CodeGen/StackSegmenter.cpp +++ b/lib/CodeGen/StackSegmenter.cpp

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 Tue, Aug 16, 2011 at 09:06:52AM +0200, Duncan Sands wrote: > thanks for working on this! As far as I know, split stacks are the only thing > special to GCC Go, otherwise the generic GCC infrastructure was enough. Not true. At least on x86_64, Go uses a different calling convention. Joerg

> thanks for working on this! As far as I know, split stacks are the only thing > special to GCC Go, otherwise the generic GCC infrastructure was enough. If that > is true then you shouldn't need to do more than what you described above, except > for poking at things until they work of course! The usual source of trouble is > when front-ends trying to write things directly to

As far as I can see (after hand-tweaking the assembly generated for a simple example), there is no problem with the calling convention. Also, go_write_export_data only seems to generate to some sort of debug information (which does not look like DWARF). However, there seems to be some problem with how LLVM handles trampolines -- I'm currently trying find out what exactly the problem is. --

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

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

Guys, regarding alloca. not only are exceptions a problem here, but just plain old "longjmp". -Peter Lawrence. On Jun 1, 2011, at 10:00 AM, llvmdev-request at cs.uiuc.edu wrote: > ------------------------------ > > Message: 4 > Date: Tue, 31 May 2011 16:55:07 -0400 > From: Rafael Avila de Espindola <rafael.espindola at gmail.com> > Subject: Re: