search for: deletebb

...sure that there is only entry into the return block. In the original model, 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...

...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 the thread at ReturnBB UNREACHABLE // <== never reaches here. So we are honest with optimizer...

...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 fiber stack updated >> free(%mem) >> (*%t) = 20 ; // undef: as the fiber memory is freed already >> coro.end(true) >> UNREACHABLE >> >> Say there was no (*%t) = 20. There is nothin...

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