[llvm-dev] Fwd: [RFC] LLVM Coroutines

[Eli Friedman via llvm-dev]

On Thu, Jun 9, 2016 at 10:16 AM, Gor Nishanov <gornishanov at gmail.com> wrote:

> Hi Eli:
>
> Thank you very much for your comments!
>
> >> If you need some sort of unusual control flow construct, make it a
> >> proper terminator instruction
>
> I would love to. I was going by the advice in "docs/ExtendingLLVM.rst":
>
>        "WARNING: Adding instructions changes the bitcode format, and it
> will
>         take some effort to maintain compatibility with the previous
> version.
>         Only add an instruction if it is absolutely necessary.
>

The point of this is that we want to strongly encourage people to look for
other solutions first... but on the other hand this isn't a blanket ban on
new instructions; pushing intrinsics too far consistently caused trouble
for exception handling in LLVM for years.

I need to think about it more, but, I am currently leaning toward the first
> option (with coro.fork and coro.end). The "f_inner" is still part of the f,
> but nicely delineated with corobegin and coro.end.
>
>   corobegin to label %coro.start
>          suspend label %retblock
>
>    corosuspend [final] [save %token] resume label %resume
>             cleanup label %cleanup
>
>     call void @llvm.coro.end();
>
> Does it look better?
>

Yes, that seems fine.  There's still the potential for non-initialization
instructions sneaking into the initialization block, but you can probably
handle it somehow.

That said, thinking about it a bit more, I'm not really sure why you need
to tie the suspend call to the branch in the first place.  What exactly is
your algorithm doing that requires it?  I mean, a naive implementation of
CoroSplit based on your llvm.experimental.coro.suspend intrinsic clones the
whole function, replaces the result of suspend calls with "true" in one
version and "false" in the other, and runs SimplifyCFG to kill the dead
code.  And even with a an algorithm that tries to be more clever, you
probably need to do some cloning anyway: presumably frontends will want to
share code between the destroy and unwinding codepaths.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160609/c0d22a76/attachment.html>