search for: coro

Hi Eli: >> semantics of the fork intrinsic... thinking about it a bit more, I think >> you're going to run into problems with trying to keep around a return block >> through optimizations: How about this? Make all control flow explicit (duh). declare i8 coro.suspend([...]) returns: 0 - resume 1 - cleanup anything else - suspend Now we can get rid of the coro.fork altogether. [...] %0 = call i8 @llvm.coro.suspend([...]) switch i8 %0, label %suspend [ i32 0, label %resume, i32 1, lab...

Hi Eli: >> Block1: >> %0 = call i8 coro.suspend() >> switch i8 %0, label suspend1 [i8 0 %return] ; or icmp + br i1 >> Suspend1: >> switch i8 %0, label %resume1 [i8 1 %destroy1] ; or icmp + br i1 >> >> This doesn't look right: intuitively the suspend happens after the return >> block runs....

...Hi all: >> >> Thank you very much for the feedback during the first round! Special >> thanks to >> Eli, Sanjoy, Hal and Chandler for their detailed public and private >> comments. >> The model is simpler now and the intrinsics have nice symmetry to them: >> coro.begin + coro.end, coro.alloc + coro.free. Compared to the previous >> RFC, >> coro.fork is gone, coro.init and coro.start are collapsed into one >> coro.begin, >> coro.suspend is three-way as opposed to two-way. coro.elide and >> coro.delete >> renamed coro.alloc...

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 int...

On Thu, Jun 9, 2016 at 1:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> Right... but that doesn't mean the call to the suspend intrinsic has to be >> the last non-terminator instruction in the basic block before you run >> CoroSplit. You can split the basic block in CoroSplit so any instructions >> after the suspend call are part of a different basic block. Then resume and >> destroy both branch to the continuation of the basic block (and run different >> codepaths based on the boolean). I love it!!!...

...s are in the second half of my reply. I would like to start with the thought experiment you suggested, as it might help to explain the behavior a little better. >> The thought experiment relevant here is that **could** you implement >> your semantics with reasonable bodies for the llvm.coro intrinsics? I can emulate **control flow** very closely with user mode thread switching APIs like make_context, jump_context. Memory behavior not so much. Library emulation ================= Let's build a fiber abstraction out of make_context, jump_context. i1 fiber_fork(i8* %mem) - clones...

...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 %...

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...

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 hoisting the store is perfectly > legal > transformation with all semantics preserved. > > Let's look at your example...

It makes sense that you would be able to do this: %save1 = llvm.coro.save() %unused = musttail call llvm.coro.resume(%some_handle) %x = llvm.coro.suspend() ... But the docs for musttail say: > The call must immediately precede a ret instruction, or a pointer bitcast followed by a ret instruction. Should this be amended to allow a musttail to be followed by llvm...

...o. 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. Having coro.fork and coro.suspend to be proper terminators (as they are) will be much cleaner. Something like: corobegin to label %start suspend label %retblock corosuspend [final] [save %token] resume label %resume cleanup label %cleanup I did consider "repurposing...

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>...

...mantics of the fork intrinsic... thinking about it a bit more, I think > >> you're going to run into problems with trying to keep around a return > block > >> through optimizations: > > Thinking about it a bit more, it is even simpler, I don't have to involve > coro.end in this case at all and should not worry about branches, RAUW-ing > coro.suspend with an appropriate constant takes care of it all. > > Here is an updated version. > 1) coro.fork is gone, gone gone!!!! > 2) coro.suspend is changed as follows: > > declare i8 coro.suspend...

(Dropped llvm-dev by accident. Putting it back) HI Eli: >> coro.barrier() doesn't work: if the address of the alloca doesn't escape, >> alias analysis will assume the barrier can't read or write the value of >> the alloca, so the barrier doesn't actually block code movement. Got it. I am new to this and learning a lot over the cours...

I have this input IR in the final cleanup block of my coroutine: // call the free function call fastcc void %22(%Allocator* %20, %"[]u8"* byval %4), !dbg !244 // based on whether this is an early return or a normal return, we want to // either return to the caller, or resume the handle of the awaiter br i1 %19, label %Resume, label %Return,...

http://llvm.org/docs/Coroutines.html#llvm-coro-size-intrinsic The @llvm.coro.size intrinsic returns a value which lowers to a constant representing the number of bytes needed for the coroutine frame of the current function. This would presumably be used to call malloc with the return value. I noticed, however, that the ex...

Here's what this function is supposed to do: // Move early uses of spilled variable after CoroBegin. // For example, if a parameter had address taken, we may end up with the code // like: // define @f(i32 %n) { // %n.addr = alloca i32 // store %n, %n.addr // ... // call @coro.begin // we need to move the store after coro.begin in the implementa...

...LLVM to not attempt to propagate information about the function body 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...

I'm going to show the same function, first normally, and then as a coroutine, and show how gdb can see the variable when it's a normal function, but not when it's a coroutine. I'd like to understand if this can be improved. I'm trying to debug a real world problem, but the lack of debug info on variables in coroutines is making it difficult. Should I f...

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...