[llvm-dev] [RFC] LLVM Coroutines

[Gor Nishanov via llvm-dev]

Hi Eli:

>> Naively, you would expect that it would be legal to hoist the store...
>> but that breaks your coroutine semantics because the global could be mutated
>> between the first return and the resume.

Hmmm... I don't see the problem. I think hoisting the store is perfectly legal
transformation with all semantics preserved.

Let's look at your example:

>> block1:
>>   suspend
>>   switch (resume, destroy, return)
>>
>> resume:
>>   store zero  to global @g
>>   doA()
>>   [...]
>>
>> destroy:
>>   store zero  to global @g
>>   doB()
>>   [...]
>>
>> return:
>>   store zero to global @g
>>   doC
>>   [...]

As written the behavior is:

  1) when we encounter a suspend during the first pass through the function,
     store 0 to @g and doC()

  2) when we encounter a suspend after coroutine was resumed
     ret void

  3) When coroutine is resumed:
     store 0 to @g and doA()

  4) When coroutine is destroyed:
     store 0 to @g and doB()

If this is a coroutine that can be resumed asynchronously from a different
thread there is a data race. For example, if resume happens before 'f' returns,
doA() can write something useful to @g, and 'f' will clobber it with zero.
But, this race is already present in the code and is not introduced by LLVM.

Let's hoist the store and see what happens:

>> block1:
>>   suspend
>>   store zero  to global @g
>>   switch (resume, destroy, return)
>>
>> resume:
>>   doA()
>>   [...]
>>
>> destroy:
>>   doB()
>>   [...]
>>
>> return:
>>   doC()
>>   [...]

Now, let's split it up:
  1. RAUW coro.suspend with -1,0,1 in f, f.resume and f.destroy
  2. remove coro.suspend in f, replace with ret void in f.resume

void f() {
  [...]
  store zero  to global @g
  doC();
  [...]
}

void @f.resume() {
entry:
  store zero  to global @g
  doA();
  [....]
}

void @f.destroy() {
entry:
  store zero  to global @g
  doB();
  [....]
}

Behavior looks exactly as before. What am I missing?

Thank you,
Gor

P.S.

Eli, thank you very much for your input. I struggled with the coro.fork for
months and in just a few days here it seems to be getting so much better!