search for: coroutines

...opposed to two-way. coro.elide and >> coro.delete >> renamed coro.alloc and coro.free. >> >> All the changes implemented and tested. Full document, (nicely formatted >> by >> github is at: >> >> https://github.com/GorNishanov/llvm/blob/coro-rfc/docs/Coroutines.rst >> >> Below is a summary of a proposal to add coroutine support to LLVM. >> The proposal is motivated primarily by the desire to support C++ >> Coroutines [1], >> however the llvm representation is language neutral and can be used >> to support coroutines in...

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. Clang + llvm coroutines allows you to take this code: generator<int> range(int from, int to) { for(int i = from; i < to; ++n) co_yield i; } int main() {...

.../2016-June/100838.html (Initial) http://lists.llvm.org/pipermail/llvm-dev/2016-July/102133.html (Round 2) 2) Get agreement on how coroutine transformation passes integrate into the optimizer pipeline. (this mail) <=== WE ARE HERE .. repeat 2) until happy 3) update IR/Intrinsics.td + doc/Coroutines.rst + doc/LangRef.rst https://github.com/GorNishanov/llvm/blob/coro-rfc/docs/Coroutines.rst 4) trickle in coroutine transformation passes + tests in digestible chunks. 5) get clang changes in (sometime after step 3). 6) fix bugs / remove limitations / add functionality to coroutine passes .. r...

Hi llvmdev! I've been working on adding coroutines to LLVM. Mentioned below is the implementation plan I'm following, for suggestions, flames and other input. Using segmented stacks is a prerequisite. The idea is to associate every coroutine with a coroutine descriptor. A coroutine descriptor consists of four words: w0, w1, w2 and w3. w0 alwa...

On 07/28/2011 05:31 PM, Sanjoy Das wrote: > Hi llvmdev! > > I've been working on adding coroutines to LLVM. Mentioned below is the > implementation plan I'm following, for suggestions, flames and other > input. Using segmented stacks is a prerequisite. I think my only comment is that, while this would probably work, implementing it in C with a bit of assembly for saving/restoring r...

...in this return block? BTW, I am speaking of the return block as if it is one block, but, it could be a dominating block over all the blocks that together run the destructors, do return value conversion, etc. Clarification: ============== >> Also, if some non-C++ language wants to generate coroutines, >> it might not have to generate the return block at all. C++ coroutines are flexible. The semantic of a coroutine is defined via traits, so you may define a coroutine that returns void. It does not have to return coroutine handle or some struct that wraps the coroutine handle. For example...

Hello all, It's been a month since my previous email on the topic, and since then I've done some initial work on porting the coroutines passes to the new pass manager. In total there are 6 patches -- that's a lot to review, so allow me to introduce the changes being made in each of them. # What's finished In these first 6 patches, I focused on lowering coroutine intrinsics correctly. With the patches applied, Clang is abl...

...lf_gas.S >> If so, I'd urge you to try to not rely on that kind of behavior. LLVM has >> unresolved issues around modeling setjmp like behavior Absolutely! This was just a thought experiment how one could implement the intrinsics in a library. One of the benefits of compiler based coroutines is that they allow to avoid all of that mess. Suspend is just a 'ret void', resume is simply a direct (or indirect) call and a coroutine state is tiny (assuming you don't use 64K arrays as local variables :-) ) >> DeleteBB: >> (*%t) = 15 ; // fine, copy of %t on a...

...y outside of the function, including by changing the attributes of the function. The expectation is that some special pass will eventually remove the attribute and enable normal optimization. So, why should we add this? Problem: coroutine structure I've recently been working on implementing coroutines for Swift. This involves embracing and extending Gor's excellent work on LLVM coroutines with an alternate code-generation pattern and ABI. (*) LLVM doesn't natively support coroutines, which means that a pre-split coroutine represented in IR looks rather artificial. (* This work has bee...

...changing the attributes > of the function. The expectation is that some special pass will eventually > remove the attribute and enable normal optimization. > > So, why should we add this? > > *Problem: coroutine structure* > > I've recently been working on implementing coroutines for Swift. This > involves embracing and extending Gor's excellent work on LLVM coroutines > with an alternate code-generation pattern and ABI. (*) LLVM doesn't > natively support coroutines, which means that a pre-split coroutine > represented in IR looks rather artificial. &...

...mption that there are few). Aye-aye. Will remove the attribute. With respect to lessening the impact of coroutine passes, one approach I tried was to look during doInitialize whether there are any uses of coroutine intrinsics and set a flag if there are any, or maybe build a set of functions with coroutines intrinsics in doInitialize, so that in runOnFunction, I can just check whether the function is in the set and skip if it is not. Then, I scared myself silly that some optimization passes can materialize new functions or new function bodies and I will miss them. So I stopped doing that. I think yo...

...luding by changing the attributes of the function. The expectation is that some special pass will eventually remove the attribute and enable normal optimization. > > So, why should we add this? > > Problem: coroutine structure > > I've recently been working on implementing coroutines for Swift. This involves embracing and extending Gor's excellent work on LLVM coroutines with an alternate code-generation pattern and ABI. (*) LLVM doesn't natively support coroutines, which means that a pre-split coroutine represented in IR looks rather artificial. > > (* This wo...

Hello all! (+cc Vedant Kumar, who I've been told knows a lot about UBSan!) I am trying to fix an assert that occurs when the transforms in llvm/lib/Transforms/Coroutines are applied to LLVM IR that has been generated with UBSan enabled -- specifically, '-fsanitize=null'. You can see an example of the assert in this 26-line C++ file here: https://godbolt.org/g/Gw9UZq Note that without the '-fsanitize=null' option this compiles fine, but when that o...

...t it is that it should be possible to lower a coroutine >> to a thread rather than performing the state machine transformation. That is very good point! It is a great way to think about the semantics. Unfortunately, I cannot avoid doing state machine transformation in general case. For the coroutines with "initial_suspend" point, i.e. it suspends before entering user authored body, it is very easy. future<void> f(Params) { // <initial suspend point> at open curly char buf[N]; ... fill buff with stuff await async_send(buf); // <suspend-point> ... do...

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

> On Mar 19, 2018, at 3:44 PM, Brian Gesiak <modocache at gmail.com> wrote: > > Hello all! > (+cc Vedant Kumar, who I've been told knows a lot about UBSan!) > > I am trying to fix an assert that occurs when the transforms in llvm/lib/Transforms/Coroutines are applied to LLVM IR that has been generated with UBSan enabled -- specifically, '-fsanitize=null'. > > You can see an example of the assert in this 26-line C++ file here: https://godbolt.org/g/Gw9UZq <https://godbolt.org/g/Gw9UZq> > > Note that without the '-fsani...

Hi Sanjoy: >> Now in the above CFG %val can be folded to 10, but in reality you need >> a PHI of 10 and 20 Quick answer: folding %val to 10 is OK, but, I would prefer it to be 'undef' or even catch it in the verifier as it is a programmer/frontend error. Details are in the second half of my reply. I would like to start with the thought experiment you suggested, as it might

I'm very interested in seeing support for stack/context switching in LLVM, if only for prototyping language ideas. I'm particularly interested in mechanisms that would make it possible to implement full asymmetric coroutines as described in "Revisiting Coroutines" (Moura & Ierusalimschy, Feb 2009 TOPLAS). From skimming the thread and looking at the llvm-stack-switch wiki, it looks like you're headed more in the direction of symmetric coroutines. I've read that there is a Lua JIT based on LLVM, bu...

...fferent solutions. I will dare a comment on this topic well over my head, so my answer will probably only reflect my ignorance on the deepness of the subject, however, in any case i hope to get some clarification of my concepts let me say more before i go into the idea on this post: I've used coroutines a lot in my c++ programming, and certainly when you work a lot of time with a hammer, everything starts looking like a nail. However, it has always seemed to me that exception handling (at least on c++) is just a particular syntax of a subset of coroutine semantics: void f() { throw 1; } void h()...

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