search for: corosplit

...nbounds %StackTrace, %StackTrace* %error_return_trace, i32 0, i32 1 %7 = getelementptr inbounds %"[]usize", %"[]usize"* %6, i32 0, i32 0 %8 = getelementptr inbounds [1 x i64], [1 x i64]* %error_return_trace_addresses, i64 0, i64 0 store i64* %8, i64** %7, align 8 however CoroSplit does not spill it. we write through the pointer, which writes to the fn stack data. then there is a suspend point, and the data becomes corrupt. then we read through the pointer and get corrupt data. this is because %error_return_trace_addresses should be spilled. is there a way for a frontend to...

...LVM coroutines are functions that have one or more `suspend points`. When a suspend point is reached, the execution of a coroutine is suspended and control is returned back to its caller. A suspended coroutine can be resumed to continue execution from the last suspend point or it can be destroyed. CoroSplit Pass: (CGSCC Pass @ new extension point EP_CGSCCOptimizerLate) --------------- Overall idea is that a coroutine is presented to an llvm as an ordinary function with suspension points marked up with intrinsics. We let the optimizer party on the coroutine as a single function for as long as possible...

...prevents >> sinking "(*%t) = 15" from before the free (where it is legal) to after >> the free (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)....

...e %31 = load i8*, i8** %14, align 8, !dbg !244 call void @llvm.coro.resume(i8* %31), !dbg !244 // after resuming the awaiter, we return to the caller br label %Return, !dbg !244 Return: ; preds = %Resume, %CheckFree ret i8* undef, !dbg !244 When CoroSplit creates the destroy function for this coroutine, it generates this: call fastcc void %2(%Allocator* %0, %"[]u8"* byval %.reload.addr4), !dbg !296 unreachable How did that unreachable get there? What happened to my code above to resume or return to the caller? -------------- next pa...

...ad_self with a new attribute, say "ThreadConstAttr". Next, in the emitted IR, functions with "ThreadConstAttr" will have a new IR attribute, say "thread_readnone". Finally, there are two possible sub-solutions to handle this new IR attribute: a) We add a new Pass after CoroSplitPass that changes all the "thread_readnone" attributes back to "readnone". This will allow it to work properly prior to CoroSplit, and still provide a chance to do CSE after CoroSplit. This approach is simplest to implement. b) We never remove "thread_readnone". However...

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

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!!! it is...

Hi Eli: Thank you very much for your comments! >> If you need some sort of unusual control flow construct, make it a >> proper terminator instruction I would love to. 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

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.coro.suspend() ? Regards,

....suspend is replaced with a blocking call waiting on whatever will signal that the thread can resume. ===================== Two function approach ===================== Even though I pushing back against it, I might prototype it and see how it looks anyways. I will outline in CoroEarly and during CoroSplit inline it back so that I can build the coroutine frame properly. But even as I am typing it, it just feels too much. Look what we are trying to solve is this. %0 = coro.suspend() ; A thing should not be hoisted here %first = icmp %0, 0 ; or here br %first,...

(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