search for: some_code_creating_t

...el, ReturnBB had two entries, one from coro.fork, another from fall-through from the delete block. T coro() { %mem = malloc(...); if (!coro.fork()) { Body Of The Coroutine With Suspends and All The Fun DeleteBB: free(%mem) coro.end() } ReturnBB: return some_code_creating_T(); } In the original model, coro.end is replaced with `no-op` in start, 'ret void' in clones (*) suspend is replaced with `br %return` in start, 'ret void' in clones Let's tweak it. Add an i1 %fallthru parameter to coro.end. Now the behavior is: in clones coro.end beha...

...number) Now let's walk through this example in the fiber model: T coro() { %t = alloca %mem = malloc(...); (*%t) = 10 if (coro.fork()) { // switches to fiber at label Start ReturnBB: %val = *%t // will be 10, as fiber has its own copy return some_code_creating_T(%val); } Start: Body Of The Coroutine With Suspends and All The Fun DeleteBB: (*%t) = 15 ; // fine, copy of %t on a fiber stack updated free(%mem) (*%t) = 20 ; // undef: as the fiber memory is freed already coro.end(true) // switches back to th...

...(where it is not). %t is an unescaped alloca, and LLVM can >> move around loads from and stores to these (as a first approximation) >> as it pleases. Good point. During CoroSplit I should sink CoroutineFrame deallocation all the way down to coro.end(). >> So when you say "some_code_creating_T()" are there restrictions on >> what kind of code there could be as part of the creation logic (I've >> so far assumed that it can be arbitrary code). You are right. It *is* arbitrary code. In my reply to you earlier I had a particular use case in mind, where you should not to...

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