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 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Adds-relevant-command-line-options.patch Type: text/x-diff Size: 2250 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110530/f9c0f8ca/attachment.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Adds-a-new-StackSegmenter-pass.patch Type: text/x-diff Size: 6941 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110530/f9c0f8ca/attachment-0001.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Implements-prologue-for-X86.patch Type: text/x-diff Size: 7879 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110530/f9c0f8ca/attachment-0002.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Adds-some-basic-documentation.patch Type: text/x-diff Size: 3028 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110530/f9c0f8ca/attachment-0003.patch>
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
On Wednesday 01 June 2011 02:25 AM, Rafael Avila de Espindola wrote:> 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.Okay, will do.> > *) You use "stack block" in some places and stacklets in others.Will fix.> > *) 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? >I want to get an rough version working ASAP (hopefully by next Monday); after which I'll go on to implement support for the red zone. About heap allocating allocas: I guessed we could just have the stacklet cleanup function free all the alloca blocks associated with the stacklet it is freeing (the stacklet will have a list of heap-allocated alloca blocks). While this would not ensure that all such allocas are freed as soon as possible; it will ensure that they are freed eventually so we don't have a leak. Perhaps, at a later stage, code can be added that frees the relevant alloca-heap blocks as the function returns; and only if an exception was thrown will the "backup" mechanism of the cleanup function freeing the blocks will be used.> *) You intend for the runtime to be compatible with the gcc one? Their > stack allocating function is called __morestack...I'm not sure. Does it make sense to have a initial version that generates calls the libgcc rather than compiler-rt? -- Sanjoy Das http://playingwithpointers.com