[LLVMdev] RFC: GSoC Project

Sanjoy Das sanjoy at playingwithpointers.com
Wed Mar 23 03:07:02 PDT 2011


Hi All!

I will be applying to the LLVM project for this GSoC, and I wanted some 
preliminary sanity check on my project idea.

I intend to implement split (segmented) stacks for LLVM (like we have in 
Go, and as being implemented for GCC [1]). A lot of what follows is 
lifted from [1]; I will progressively add more details as I get more 
familiar with the LLVM codebase.

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 (using the first two words in the block as 
the next and previous pointers).

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 sized allocas, and for ones which do, we can assume some 
worst-case upper bound. The prologue can then call an intrinsic (let's 
call it llvm.adjust_stack) which allocates a new block (possibly by 
delegating this to a user-provided callback), copies the arguments, 
saves the previous stack pointer (in the new block), and adjusts the 
next and previous pointers. It will also have to adjust the stack 
pointer, and the frame pointer, if it is being maintained. Cleanup can 
be done by hijacking the return value, as also mentioned in [1]. It 
might make sense to leave the allocated blocks around, to prevent 
re-allocating the next time the program needs more stack space.

DWARF info can be generated as follows: since we know the offset of base 
of the stack frame from the stack pointer (or we are maintaining a frame 
pointer), we can always say whether the concerned call frame is the 
first call frame or not. In the second case, all the previous register 
values can be computed as usual, and in the first case, we will add an 
extra indirection, involving looking up the stack pointer saved in this 
block's header.

One thing I'd really like some input on is whether implementing split 
stacks would be useful enough to warrant the effort (especially keeping 
in mind that this is pretty useless on 64 bit architectures).

[1] http://gcc.gnu.org/wiki/SplitStacks
-- 
Sanjoy Das
http://playingwithpointers.com



More information about the llvm-dev mailing list