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

[Eli Friedman via llvm-dev]

On Wed, Jun 8, 2016 at 10:57 PM, Gor Nishanov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all:
>
> Below is a proposal to add experimental coroutine support to LLVM. Though
> this
> proposal is motivated primarily by the desire to support C++ Coroutines
> [1],
> the llvm representation is language neutral and can be used to support
> coroutines in other languages as well.
>

I looked over the proposal... a few comments:

1. This adds a lot of intrinsics, and they have weird semantics.  This is
bad in general; the more weirdness you add to the IR, the more you'll
struggle to make the optimizer actually understand what you're doing.  And
magic pattern matching *will* break.  You've already pointed out the issue
with branches.  (It's actually worse than you think: there isn't any
guarantee there will even be a branch when you've thrown the optimizer at
it.)  The save intrinsic says "Its return value should be consumed by
exactly one `coro.suspend` intrinsic.", but it might have zero uses by the
time your lowering pass runs.  You could end up with code getting inserted
before llvm.experimental.coro.fork.
2. If you need some sort of unusual control flow construct, make it a
proper terminator instruction; don't try to glue your intrinsic to a normal
branch instruction.  A new kind of terminator instruction might be
appropriate.  Or maybe you can make "invoke" work for you.
3. Maybe you could reduce the amount of magic involved by splitting the
initialization into a separate function?  So the initialization is always
just something like "f(int x) { frame = init(); f_inner(x, frame); return
frame; }", and you don't have to deal with the weirdness of fork().

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