[llvm-dev] RFC: LLVM Coroutine Representation, Round 2

Antoine Pitrou via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 20 04:44:04 PDT 2016


Hi,

On Mon, 11 Jul 2016 06:47:09 -0700
Gor Nishanov via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Hi all:
> 
> Thank you very much for the feedback during the first round! Special thanks to
> Eli, Sanjoy, Hal and Chandler for their detailed public and private comments.
> The model is simpler now and the intrinsics have nice symmetry to them:
> coro.begin + coro.end, coro.alloc + coro.free. Compared to the previous RFC,
> coro.fork is gone, coro.init and coro.start are collapsed into one coro.begin,
> coro.suspend is three-way as opposed to two-way. coro.elide and coro.delete
> renamed coro.alloc and coro.free.
> 
> All the changes implemented and tested. Full document, (nicely formatted by
> github is at:
> 
>   https://github.com/GorNishanov/llvm/blob/coro-rfc/docs/Coroutines.rst

Reading through that document, I have a couple of questions (maybe
overlooking or misunderstanding some important explanations):

- As the caller of a coroutine, how do I know whether a coroutine
  reached its cleanup point or not?  This seems essential for
  implementing iterators and looping on them, yet @llvm.coro.done only
  works if a particular suspend point was designated as "final" (which
  doesn't sound possible to do in the general case, i.e. halting
  problem).

- Is the promise type restricted to atomic LLVM types, or can I use
  @llvm.coro.promise.p0i8 (together with a bitcast) if the promise is an
  arbitrary complex structure?

- Is the promise allocated/copied inside the coroutine frame?  If not,
  how does the sharing work even if the coroutine is passed to different
  callers?

Regards

Antoine.




More information about the llvm-dev mailing list