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: [LLVMdev] [Segmented Stacks] Week 1
> To: Sanjoy Das <sanjoy at playingwithpointers.com>
> Cc: llvmdev at cs.uiuc.edu
> Message-ID: <4DE555AB.9050302 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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 could add the description you used for the GSoC to the
> segmented-stacks document too? Maybe at the end and under a "not yet
> implemented" section, but having it all in one place is probably
> useful.
>
> *) You use "stack block" in some places and stacklets in others.
>
> *) You mention that variable sized alloca's are handled by using the
> heap. This is an interesting idea, but you have to be careful to avoid
> leaks if exceptions are enabled.
>
> *) If I remember correctly, you wanted to fold the red zone in the
> "do I
> need more stack" check, but I seed that you have a
> !EnableSegmentedStacks in the Red Zone check. Have you decided not
> to do it?
>
> *) You intend for the runtime to be compatible with the gcc one? Their
> stack allocating function is called __morestack...
>
>> [1] https://github.com/sanjoy/llvm/tree/segmented-stacks
>>
>
> Cheers,
> Rafael
>
>
> ------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110602/87774d2d/attachment.html>
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 think of it, the presence of longjmp pretty much forces a model where stacklets are not deallocated on return, just reused if stack grows again. We discussed the use of allocas a bit in the rust channel. One idea that came out was that maybe we only need to support the "simple" case of allocas that are in the entry bb. That would still be a bit nasty as finding that size this late in the pipeline would not be trivial. I think my suggestion for now would be to not support frames with allocas and afterwards, if time allows, we can add a llvm intrinsic that tells the codegen how much stack will be used by dynamic allocas. That way a FE that really wants split stacks and really wants dynamic allocas could write something like define void @foo(i32 a, i32 b) { %how_much_dynamic_space_this_frame_needs = add i32 %a, %b llvm.dynamic_alloca_use(%how_much_dynamic_space_this_frame_needs) %x = alloca i8, i32 a; %y = alloca i8, i32 b; .... }> -Peter Lawrence. >Cheers, Rafael
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 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 think of it, the presence of longjmp pretty much > forces a model where stacklets are not deallocated on return, just > reused if stack grows again.Perhaps only longjmp/exception throws need to not free stacklets- returns still do. 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. For example, the natural way to implement the map function over lists is: let rec map f lst match lst with | x :: xs -> (f x) :: (map f xs) | [] -> [] ;; Interestingly enough, this is also the fastest implementation of map. But it's not tail recursive- which means if you pass in a list long enough, you run out stack space and your program blows up. So you end up writing a much more complicated version which is also slower, but which is tail recursive. I'd love to have virtual infinite stacks- stacks which expanded as needed, but got freed when no longer needed. That means being tail recursive goes back to being nice, not necessary. Just my $0.02. Brian