Displaying 20 results from an estimated 4000 matches similar to: "[LLVMdev] [PATCH] Segmented Stacks"
2011 Jul 14
0
[LLVMdev] [PATCH] Segmented Stacks
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
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 Jun 23
2
[LLVMdev] [Segmented Stacks] Week 1
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
2011 Aug 11
2
[LLVMdev] Segmented Stacks: Breaking libgcc compatibility
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
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 Jun 23
0
[LLVMdev] [Segmented Stacks] Week 1
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
2011 Jun 13
0
[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
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 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 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 Aug 15
4
[LLVMdev] Segmented Stacks: Pre-midterm work
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
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 15
0
[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
2011 Oct 18
3
[LLVMdev] Fixing segmented stacks
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
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 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
2013 Jun 03
2
[LLVMdev] LLVM/Clang research questions
Hi Duncan,
It doesn't appear to be what I'm looking for as there is copying of the old
stack to the new stack. Additionally, according to the LLVM docs on
segmented stacks (http://llvm.org/releases/3.0/docs/SegmentedStacks.html)
the stacklings are allocated memory from the heap. Since this places them
all on the same memory segment, a read/write from one stackling could
technically
2013 Jun 03
0
[LLVMdev] LLVM/Clang research questions
Hi Brent,
You're correct. The segmented stack model is intended for performance, not security. Its goal is to allow lightweight threads to be very cheaply allocated and destroyed.
For your model, you would most likely want to use different address spaces for the different memory types. Currently, clang does not allow you to define the address space of variables with automatic storage
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 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