[LLVMdev] RFC: GSoC Project
jo at durchholz.org
Sun Apr 10 22:57:08 PDT 2011
(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.
More information about the llvm-dev