search for: returnbb

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

...se) coro.destroy = fiber_join(%mem, i1 true) coro.size == 1,000,000 (or some other big 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)...

...her big 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 ; //...

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