search for: destroy1

...or): SetUp2 SetUp1 ^ ^ | | | | Destroy2---->PredSU <----SU ^ ^ ^ | | | | | | ----------- | --------- | | | Destroy1 ^ | In this example there are two successors of 'PredSU' with type getCallFrameDestroyOpcode (Destroy) and one is a successor of the other. Taking the successor of the two Destroys (Destroy1), noted that it's matching getCallFrameSetupOpcode (Setup1)...

...have to have a load here? =================================== >> block1: >> %first_time = load... <--- What are we loading here? >> br i1 %first_time, label return, label suspend1 >> >> supend1: >> %0 = coro.suspend() >> switch %0 (resume1, destroy1) Can we use three way coro.suspend instead? 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 One problem I can see is that someone can write a pass that migh...

sorry, Just noticed that the diagrams have 'Destroy' & 'SetUp' the wrong way around! Robert ________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Robert Lytton [robert at xmos.com] Sent: 21 August 2013 18:34 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] PrescheduleNodesWithMultipleUses() causing failure in

Hi, I have reasoned through and believe the problem is with the PrescheduleNodesWithMultipleUses. Take the following DAG (arrow to predecessor): Destroy Destroy ^ ^ | | | | SetUp----->PredSU <-----SU ^ ^ ^ | | | | | | ----------- |

...gt; Outstanding issues > ============ > > 1. Is it too aggressive in searching predecessors and successors? > Should the algorithm give up and assume the worst if the depth of > search reaches a predefined limit? > > 2. Should the initial search for 'SetUp1' and 'Destroy1' only search along > chains? viz conditional upon II->isCtrl() > The code is a kludge to work around a particular symptom of a deeper bug in the underlying scheduling algorithm. It's entirely possible that you've found a real bug in it; feel free to check in the fix if you'...

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

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 semantics. The following two things are distinct concepts: * Coroutine is considered suspended * Coroutine returns c...