[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