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