<div dir="ltr"><div>What I am getting at, is that ideally the parameters/return value of generator.send() should become parameters/return value of @f.Resume:<br>    define <return type> @f.Resume(%f.Frame* %FramePtr, <input type> %Param);<br><br></div><div>They don't need to be allocated in the coroutine frame at all.  Do you think that LLVM will be able to perform such an optimization?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 21, 2016 at 11:43 AM, Gor Nishanov <span dir="ltr"><<a href="mailto:gornishanov@gmail.com" target="_blank">gornishanov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Vadim:<br>
<span><br>
> Does you design support resumption with parameter(s)?  (such as Python's<br>
> generator.send(x)).  I suppose the "promise" could be used for passing data<br>
> both ways,<br>
<br>
</span>Correct.<br>
<br>
The docs/Coroutines.rst states that:<br>
<br>
   "A coroutine author or a frontend may designate a distinguished `alloca`<br>
    that can be used to communicate with the coroutine."<br>
<br>
What kind of communication happens is determined by the source language<br>
coroutine constructs. An example later in the section shows how, as a consumer<br>
of a coroutine, you can read the data from the promise. But that communication<br>
can go the other way if you, instead, will be storing into the promise in main,<br>
and loading from it in the coroutine.<br>
<br>
coro.promise intrinsic gives you the address of the promise associated with a<br>
particular coroutine instance and you (as frontend writer, or coroutine library<br>
designer is free to do whatever you want with it).<br>
<span><br>
> please mention this explicitly in the design doc.<br>
<br>
</span>Would you suggest changes to the exact wording to make it clearer? I put it up<br>
for review at: <a href="https://reviews.llvm.org/D22603" rel="noreferrer" target="_blank">https://reviews.llvm.org/D22603</a>, so you can just mark up the<br>
changes you would like to see.<br>
<span><br>
> Also, how is loading/storing to promise going to be lowered?<br>
<br>
</span>The coro.promise intrinsics just gives you an address of the coroutine promise.<br>
You, as frontend / library writer, know what is the promise and you emit<br>
appropriate load or stores instructions.<br>
<br>
If you have a synchronous scenario and a promise is plain int, you would use<br>
plain loads and stores. If your promise is some complicated data structure<br>
which has atomics and you use it from different threads, you would use<br>
appropriate loads, stores, fences and synchronization primitives.<br>
<br>
But all this is out of scope for docs/Coroutines.rst . It is up to the frontend,<br>
library writer to decide how it wants to use the promise. The only special<br>
handling that LLVM does for the coroutine promise is:<br>
<br>
1) places the promise at deterministic offset in the coroutine frame<br>
2) allows you to get an address of the promise given a coroutine handle and<br>
   vice versa.<br>
<br>
Cheers,<br>
Gor<br>
<br>
P.S. If you'd like to see a library implementation of a generator, please see:<br>
<br>
Generator itself:<br>
<a href="https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/Inputs/generator.h" rel="noreferrer" target="_blank">https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/Inputs/generator.h</a><br>
<br>
coroutine_handle (a C++ level abstraction mapping to llvm intrinsics)<br>
<a href="https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/Inputs/coroutine.h" rel="noreferrer" target="_blank">https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/Inputs/coroutine.h</a><br>
<br>
and the use:<br>
<br>
<a href="https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/generator.cpp" rel="noreferrer" target="_blank">https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/generator.cpp</a><br>
<br>
Well, if start looking at those tests, you may enjoy coroutines in C via macros,<br>
lowered to the same coroutine intrinsics :-).<br>
<br>
<a href="https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/coro.c" rel="noreferrer" target="_blank">https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/coro.c</a><br>
<br>
and<br>
<br>
<a href="https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/Inputs/coro.h" rel="noreferrer" target="_blank">https://github.com/GorNishanov/clang/blob/coro-rfc/test/Coroutines/Inputs/coro.h</a><br>
</blockquote></div><br></div></div>