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 working on supporting variable arguments before I started to clean up my work and roll a patch series. The varargs work is not completed yet; and I recall having a discussion on this list some time back [2] about adding support for co-routines. Does postponing the vararg work and seeing if co-routines can be implemented sound more useful (since we should be able to cheaply create and destroy stacks now). I understand that segmented stacks will primarily be used by managed languages; does support for varargs seem important enough in such cases? Thanks! [1] I'm working on implementing segmented stacks as a part of GSoC '11. [2] The previous discussion has concluded with a suggestion of adding three intrinsics to LLVM: llvm.stacknew, llvm.stackswitch and llvm.stackdestroy; which should be enough to allow the frontend developer to implement his or her own co-routining semantics. -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Adds-a-command-line-option-segmented-stacks-to-enabl.patch Type: text/x-diff Size: 1644 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110714/1955e17f/attachment.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Adds-a-StackSegmenter-pass.patch Type: text/x-diff Size: 6959 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110714/1955e17f/attachment-0001.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Implements-prologue-code-emission-for-X86.patch Type: text/x-diff Size: 9781 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110714/1955e17f/attachment-0002.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Adds-a-new-SelectionDAG-node-and-two-pseudo-instruct.patch Type: text/x-diff Size: 4335 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110714/1955e17f/attachment-0003.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Adds-support-for-variable-sized-allocas.patch Type: text/x-diff Size: 10712 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110714/1955e17f/attachment-0004.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Adds-some-basic-test-code.patch Type: text/x-diff Size: 2075 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110714/1955e17f/attachment-0005.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Adds-some-preliminary-documentation.patch Type: text/x-diff Size: 6384 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110714/1955e17f/attachment-0006.patch>
On 07/14/2011 12:07 PM, Sanjoy Das 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 small > chunks, I'd like to have some specific feedback on where my work stands > in terms of mergeability.The patches look great! Just some comments: Can you move the command line condition to addCommonCodeGenPasses instead of returning early from runOnMachineFunction? That should avoid printing the pass with -debug-pass=Arguments if it is not used for example. runOnMachineFunction only needs to return true if changes were made. Maybe adjustForSegmentedStacks should return a bool. It might be a good idea to add a comment that the particular stack size checks sequences are important as the linker patter matches them. A micro optimization in EmitLoweredSegAlloca: can you reused the sub if we find out that we have enough stack space? + if (!Is64Bit) + BuildMI(mallocMBB, DL, TII->get(X86::SUB32ri), physSPReg).addReg(physSPReg) + .addImm(16); You can merge this if with the else just before it. In the test: +; Just to prevent the alloca from being optimized away +define void @dummy(i32* %val, i32 %len) { + ret void +} + Probably better to just declare it. You should use X32-NEXT: and X64-NEXT: when the instructions are required to be on the next line.> Secondly, I had been working on supporting variable arguments before I > started to clean up my work and roll a patch series. The varargs work is > not completed yet; and I recall having a discussion on this list some > time back [2] about adding support for co-routines. Does postponing the > vararg work and seeing if co-routines can be implemented sound more > useful (since we should be able to cheaply create and destroy stacks > now). I understand that segmented stacks will primarily be used by > managed languages; does support for varargs seem important enough in > such cases?>> Thanks! > > [1] I'm working on implementing segmented stacks as a part of GSoC '11. > > [2] The previous discussion has concluded with a suggestion of adding > three intrinsics to LLVM: llvm.stacknew, llvm.stackswitch and > llvm.stackdestroy; which should be enough to allow the frontend > developer to implement his or her own co-routining semantics.If not adding coroutines to llvm, are these intrinsics necessary? We are discussing implementing something like it in rust, but it would probably be implemented with an assembly function that saves the registers to the stack and jumps to the scheduler. From the caller point of view, that function just takes a long time return. One advantaged I see in having them in llvm that it could have some nice iterations with the split stacks. For example, the space left check could account for space used by a possible call to stackswitch etc. Cheers, Rafael
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 small > chunks, I'd like to have some specific feedback on where my work stands > in terms of mergeability. > > Secondly, I had been working on supporting variable arguments before I > started to clean up my work and roll a patch series. The varargs work is > not completed yet; and I recall having a discussion on this list some > time back [2] about adding support for co-routines. Does postponing the > vararg work and seeing if co-routines can be implemented sound more > useful (since we should be able to cheaply create and destroy stacks > now). I understand that segmented stacks will primarily be used by > managed languages; does support for varargs seem important enough in > such cases? > > I think I was the one who was interested in support for coroutines. Mylanguage doesn't currently use variable arguments, but there might be others who would find it useful.> Thanks! > > [1] I'm working on implementing segmented stacks as a part of GSoC '11. > > [2] The previous discussion has concluded with a suggestion of adding > three intrinsics to LLVM: llvm.stacknew, llvm.stackswitch and > llvm.stackdestroy; which should be enough to allow the frontend > developer to implement his or her own co-routining semantics. > > -- > Sanjoy Das > http://playingwithpointers.com > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110714/071f159f/attachment.html>
On Thu, Jul 14, 2011 at 4:20 PM, Talin <viridia at gmail.com> wrote:> 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 small >> chunks, I'd like to have some specific feedback on where my work stands >> in terms of mergeability. >> >> Secondly, I had been working on supporting variable arguments before I >> started to clean up my work and roll a patch series. The varargs work is >> not completed yet; and I recall having a discussion on this list some >> time back [2] about adding support for co-routines. Does postponing the >> vararg work and seeing if co-routines can be implemented sound more >> useful (since we should be able to cheaply create and destroy stacks >> now). I understand that segmented stacks will primarily be used by >> managed languages; does support for varargs seem important enough in >> such cases? >> >> I think I was the one who was interested in support for coroutines. My > language doesn't currently use variable arguments, but there might be others > who would find it useful. > > >> Thanks! >> >> [1] I'm working on implementing segmented stacks as a part of GSoC '11. >> >> [2] The previous discussion has concluded with a suggestion of adding >> three intrinsics to LLVM: llvm.stacknew, llvm.stackswitch and >> llvm.stackdestroy; which should be enough to allow the frontend >> developer to implement his or her own co-routining semantics. >> >> Actually, now that I think of it there's something I need that is ofhigher priority (for me anyway) than either of the things you mention: Will I still be able to iterate through stack frames for purposes of garbage collection? In other words, if I use the segmented stack feature, will I need to modify my code that traces roots on the stack? Here's what the current code looks like: http://code.google.com/p/tart/source/browse/trunk/runtime/lib/gc_common.cpp#155> -- >> Sanjoy Das >> http://playingwithpointers.com >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > > -- > -- Talin >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110714/c7eccd1c/attachment.html>