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

[Jeffrey Yasskin]

On Tue, Apr 20, 2010 at 5:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> 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.

Good point about the relative cost of copying the stack. I'll suggest
the "main" context to them.

>> 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.

I guess I mean that the relevant data has to be inside the context
data. Registers would accomplish that, but they're not necessary.

Jeffrey