[PATCH] D22603: [coroutines] Part 1 of N: Documentation

[Gor Nishanov via llvm-commits]

GorNishanov added a comment.

In https://reviews.llvm.org/D22603#492436, @dberris wrote:

> Some questions (not really blockers but I think is worth addressing somewhere):
>
> - Are the coroutines guaranteed to "leak" if they are never run to full completion?


A suspended coroutine can be always destroyed by a call to coro.destroy. Note that in the Coroutines.rst, I always say: "runs to completion or destroyed via call to the coro.destroy. Of course, it is the frontend responsibility to correctly setup resume and destroy control flow for every coro.suspend.

> - Is there a way to explicitly "clone" the state of a coroutine so that it can be restored to a previous state? The use case is for running the same suspended coroutine in different threads, perhaps because there's some non-determinism involved.


I don't know how to deterministically clone the coroutine state at LLVM level. Consider:

  generator<Instruction*> foo() {
     SmallVector<Instruction*, 8> WorkList;
     fillTheWorkList(WorkList);
     for (auto It = WorkList.begin(), E = WorkList.end(); It != E; ++It)
        co_yield *It;
  }

To be able to clone this coroutine, LLVM needs to understand when iterator It and E point to the coroutine frame itself (when WorkList contains less than 8 instructions), in this case, you would need to adjust It and E to point at the new memory. If WorkList contains more than 8 instructions, to clone, you would need to know what allocator to use to clone the WorkList for your cloned coroutine.

> - Will the escape analysis figure out whether there are resources that need cleaning up once execution has flowed through resume points? Say for example, there's a local variable in the preamble that never gets touched again in the resume points -- will the analysis be able to see that there aren't references anymore in the resume points? i.e. is it possible to do just in lowering, or do you need to teach some of the other optimisations about what the final layout would be for coroutines to be able to make these kinds of optimisations?


This is very exciting topic! We can do that review when we will be looking at CoroutineFrameBuilder.cpp patch. Or, if you think it is a good idea, before even getting to the patch, I can open a discussion on llvm-devs on the algorithm itself. Let me know what do you think works best.

> I don't know if these should be documented here or somewhere else (and if they're been asked before then apologies for being late to the party).


I think I may add a Q&A section at the end of Coroutines.rst to address frequently asked questions. (Not necessarily as a part of this patch).


https://reviews.llvm.org/D22603