[LLVMdev] Proposal: stack/context switching within a thread

[Kenneth Uildriks]

On Fri, Apr 16, 2010 at 9:30 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
> On Sun, Apr 11, 2010 at 10:07 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
>> I'll forward your next draft back to the stackless folks, unless you
>> want to pick up the thread with them.
>
> Their reply: http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4475

(From the reply)
> But any function call we perform after the
> swapcontext() may trample the unsaved stack, if the source and destination stack positions
> overlap.

I'm having trouble visualizing that situation.  Is there a "main"
context that will handle all this saving and restoring of stacks?  If
so, does it actually share stacks with other contexts in the way
they're expected to share it with each other?

>
> Instead of @llvm.getcontextstacktop(%context), they want
> @llvm.getcurrentstacktop() so that they can copy the stack out before
> switching, and copy it back in after switching. I'm not sure this
> exactly works either, since before "copying the stack back", any
> allocas are pointing at old-frame data and so are invalid. They'd need
> to guarantee that any relevant data is in machine registers rather
> than the stack during the switch, but LLVM doesn't provide a way to do
> that. The cleaner way to do this is to switch to an intermediate stack
> scheduler context with its own stack, have it replace the stacks, and
> then switch to the target context back on the original stack. But that
> requires two swapcontext() calls, which seems less than idea
> performance-wise.

OK, I see you don't want to have a "main" context that does this and
dispatches other contexts if it can be avoided.  Compared to copying
stacks, though, I'm not sure that two swapcontexts will be that bad,
especially if we don't implement them as posix library function calls.

>
> Since the backend _can_ ensure that the relevant data is in machine
> registers, do you think it makes sense to provide a swapcontext() that
> also moves the stack? Or is there another way to do this that I'm
> missing?

Can it really ensure that on all targets?  Some of them don't exactly
have an abundance of registers.