search for: msg00429

Having read through Stackless Python's web pages a bit: 1. They're doing pretty much what I'd like to do, except that I don't want to be tied to a particular language and I'd like to be able to use the stack. (Also, stack use is inescapable with LLVM, as far as I can tell). 2. We should be able to support "hard switching" in Stackless Python by adding a

On the other hand, stack manipulation really ought to be handled by the target, since only the target knows the details of how the stack is laid out to begin with. Also, if we have stack manipulation calls in the IR, optimization quickly becomes very difficult. Unless we just allow optimizers to ignore the stack manipulations and assume they're doing the "right" thing. On the

..."right" thing. > > On the gripping hand, we don't want the target emitting memory > allocation calls in order to grow the stack (unless a function pointer > to malloc or its equivalent is passed in from the IR). In gcc's split-stacks (http://gcc.gnu.org/ml/gcc/2009-02/msg00429.html; I got the name wrong earlier), Ian planned to call a known global name to allocate memory (http://gcc.gnu.org/ml/gcc/2009-02/msg00479.html). I'm not sure what he actually wound up doing on the gccgo branch. LLVM could also put the allocation/deallocation functions into the context, althou...

...gt; >> On the gripping hand, we don't want the target emitting memory >> allocation calls in order to grow the stack (unless a function pointer >> to malloc or its equivalent is passed in from the IR). > > In gcc's split-stacks > (http://gcc.gnu.org/ml/gcc/2009-02/msg00429.html; I got the name wrong > earlier), Ian planned to call a known global name to allocate memory > (http://gcc.gnu.org/ml/gcc/2009-02/msg00479.html). I'm not sure what > he actually wound up doing on the gccgo branch. LLVM could also put > the allocation/deallocation functions into...