search for: coroear

...o.suspend will take an optional function pointer parameter and frontend will generate a little function for all the code that needs to go in between coro.save and coro.suspend. f.await(%frame) { %buf = get from %frame async_send(%buf) } in f() coro.suspend([...], &f.await) CoroEarly will do the extraction. Frontend will keep emitting coro.save/coro.suspend pairs. After CoroEarly, coro.save's will be removed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P A U S E ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Okay getting back to the switch in the return block. >> The sw...

...routine is fully enclosed in the lifetime of the caller, we remove dynamic allocation of coroutine state and replace it with an `alloca` on the caller's frame. These optimizations are done by a function pass CoroElide run by the main IPO optimization at EP_ScalarOptimizerLate extension point. CoroEarly Pass: (Function Pass @ EP_EarlyAsPossible) --------------- Pretty boring pass that lowers coroutine intrinsics that are not needed for later coroutine passes. CoroCleanup Pass: (Function Pass @ EP_OptimizerLast) -------------- Another boring pass that lowers all remaining coroutine intrinsics th...

On Fri, Jun 10, 2016 at 5:25 PM, Gor Nishanov <gornishanov at gmail.com> wrote: > Hi Eli: > > >> Naively, you would expect that it would be legal to hoist the store... > >> but that breaks your coroutine semantics because the global could be > mutated > >> between the first return and the resume. > > Hmmm... I don't see the problem. I think

I think I got it. Original model (with coro.fork and two-way coro.suspend) will work with a tiny tweak. In the original model, I was replacing coro.suspend with br %return in original function. The problem was coming from potential phi-nodes introduces into return block during optimizations. Let's make sure that there is only entry into the return block. In the original model, ReturnBB had

...coro.end(true) UNREACHABLE } Accessing anything in the coroutine frame after coro.fork "true" is undefined. As by the time you get to returnBB, the coroutine frame could already be destroyed. Both problems can be statically detected in the Verifier. Alternatively, in CoroEarly pass that runs at EP_EarlyAsPossible extension point, we can replace: %val = *%t with %val = undef (used after coro.fork() returned true) and free(%mem) (*%t) = 20 with @llvm.trap() ; used after frame is destroyed...

Hi Sanjoy, >> I'm not familiar with fiber-type APIs, but I assume fiber_fork is like >> setjmp, in that it can "return twice"? Yes, user-mode stack switching API are somewhat similar to setjmp. Here are links to a doc page and implementation, just in case you are curious: http://www.boost.org/doc/libs/1_59_0/libs/context/doc/html/context/context.html