similar to: [LLVMdev] RFC: GSoC Project

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] RFC: GSoC Project"

2011 Apr 10
2
[LLVMdev] RFC: GSoC Project
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,
2011 Apr 10
0
[LLVMdev] RFC: GSoC Project
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
2011 Mar 23
0
[LLVMdev] RFC: GSoC Project
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
2011 Apr 11
0
[LLVMdev] RFC: GSoC Project
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
2011 Mar 28
2
[LLVMdev] RFC: GSoC Project
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)
2011 Apr 11
2
[LLVMdev] RFC: GSoC Project
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
2011 Apr 11
2
[LLVMdev] RFC: GSoC Project
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: >>
2011 Apr 11
0
[LLVMdev] RFC: GSoC Project
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
2011 Aug 17
2
[LLVMdev] Segmented Stacks (re-roll)
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:
2011 Apr 11
0
[LLVMdev] RFC: GSoC Project
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 >
2011 Apr 03
1
[LLVMdev] GSoC '11: Segmented Stacks
Hi All! This is the third iteration of my GSoC proposal, which I'm mailing here for feedback. I've already posted the proposal on Melange. The proposal is in two parts. The first, which answers the questions on application template mentioned on Melange is here [1]. I've pasted the most relevant part here: ''' Implement segmented stacks inside LLVM. Once this is
2011 May 30
2
[LLVMdev] [Segmented Stacks] Week 1
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
2011 Aug 22
0
[LLVMdev] Segmented Stacks (re-roll)
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
2011 Aug 23
2
[LLVMdev] Segmented Stacks (re-roll)
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
2011 Apr 11
1
[LLVMdev] RFC: GSoC Project
(Sorry for replying to the wrong post, but the original one had gone out of scope when this occurred to me.) > On Wed, Mar 23, 2011 at 3:07 AM, Sanjoy Das > <sanjoy at playingwithpointers.com>wrote: > >> 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
2011 Jul 14
3
[LLVMdev] [PATCH] Segmented Stacks
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
2011 Aug 10
2
[LLVMdev] Segmented Stacks: Pre-midterm work
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:
2011 Jun 02
2
[LLVMdev] [Segmented Stacks] Week 1
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:
2011 Apr 19
1
[LLVMdev] RFC Patchset: Segmented stacks
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
2011 May 31
0
[LLVMdev] [Segmented Stacks] Week 1
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