search for: nishanov

...ace coro.suspend with 'br %suspend' coro.end expands as before: in f => no-op in f.resume/f.destroy => ret void (+ fancy things in landing pads) Gor On Thu, Jun 9, 2016 at 4:50 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Jun 9, 2016 at 2:33 PM, Gor Nishanov <gornishanov at gmail.com> wrote: >> >> Lowering of coro.suspend number X: >> >> 1) split block at coro.suspend, new block becomes jump point for >> resumption X >> 2) RAUW coro.suspend with i1 true in resume clone i1 false in destroy >> clone >&gt...

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

Hi David: >> How do you deal with basic blocks which appear to be used by multiple parts >> of the coroutine? We handled this in WinEHPrepare by cloning any BBs which >> were shared. I experimented with several approaches, but, cloning ended up being the simplest and most reliable. Suspend points express three different control flows that can happen at the suspend point: a

...eturn block if they weren't there, but, if frontend put them there, LLVM should not replace them with `@llvm.traps` and `undef`s either. Gor On Tue, Jun 14, 2016 at 1:25 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Gor, > > On Sun, Jun 12, 2016 at 6:40 PM, Gor Nishanov <gornishanov at gmail.com> wrote: >> 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. > > Ok. > >>>> The thought experiment relevant here is that **co...

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

On Fri, Jun 10, 2016 at 6:36 AM, Gor Nishanov <gornishanov at gmail.com> wrote: > >> If you're going down that route, that still leaves the question of the > >> 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 r...

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 =

Hi all: This question is related to a state machine generated by LLVM for a coroutine. I stripped all coroutine related details to get to the essence of the question. Let's say I have a state machine that looks like this: struct State { FnPtr Fn; State() : Fn(&SomeFunction) {} void Go() { (*Fn)(); } void Stop() { Fn = nullptr; } bool IsDone() { return Fn ==

...label %retblock corosuspend [final] [save %token] resume label %resume cleanup label %cleanup call void @llvm.coro.end(); Does it look better? Gor On Thu, Jun 9, 2016 at 1:33 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > 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...

(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 course of this thread. Thank you

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

...(x)). I suppose the "promise" could be used for passing data > both ways, but if that's the plan, please mention this explicitly in the > design doc. > Also, how is loading/storing to promise going to be lowered? > > Vadim > > On Mon, Jul 11, 2016 at 6:47 AM, Gor Nishanov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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 m...

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

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. Perhaps, but, that is not the intended

...ipermail/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 .. repeat 6) until happy Overview: ========= LLVM coroutine...

Summary ======= There is a need for dedicated continuation-passing style (CPS) calls in LLVM to support functional languages. Herein I describe the problem and propose a solution. Feedback and/or tips are greatly appreciated, as our goal is to implement these changes so they can be merged into LLVM trunk. Problem ======= Implementations of functional languages like Haskell and ML (e.g., GHC