[LLVMdev] RFC: GSoC Project

[Joachim Durchholz]

(Sorry for replying to the wrong post, but the original one had gone out 
of scope when this occurred to me.)

> On Wed, Mar 23, 2011 at 3:07 AM, Sanjoy Das
> <sanjoy at playingwithpointers.com>wrote:
>
>> 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.

What would you do if a function allocas in a loop? The programmer would 
know that the loop won't execute, say, more than twice, but your code 
doesn't unless you're lucky.
Or if the size to be allocated is passed in as a parameter, from code 
that the compiler does not even see in this run (think dynamically 
linked code, or alloca sizes that depend on user input).

So you'll need a fallback strategy for such situation.

Either fall back to the standard stack (but that would more-or-less 
defeat the purpose of this all).

Or make the code generators deal with stacks that have segmented 
per-function stack frames (whether that's even feasible, I have no idea, 
but I guess it wouldn't be without a gruesome amount of work, and this 
project would stay restricted to those backends that happen to get 
maintained for this).

Or deal with such cases by redirecting all allocas to the heap. With the 
possible option of moving them back to the stack where the compiler can 
indeed infer the stack requirement beforehand.

- - -

In general, I think it's a good idea to avoid too large stack frames 
anyway. Operating systems and similar infrastructure tend to assume that 
the per-function stack requirement is limited to a small constant, and 
breaking that assumption can drive them into less well-tested code, 
triggering security holes or inefficiencies.

Just my 2c, and back to lurker mode.

Regards,
Jo