<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 9, 2016 at 10:16 AM, Gor Nishanov <span dir="ltr"><<a href="mailto:gornishanov@gmail.com" target="_blank">gornishanov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Eli:<br>
<span class=""><br>
Thank you very much for your comments!<br>
<br>
</span><span class="">>> If you need some sort of unusual control flow construct, make it a<br>
>> proper terminator instruction<br>
<br>
</span>I would love to. I was going by the advice in "docs/ExtendingLLVM.rst":<br>
<br>
       "WARNING: Adding instructions changes the bitcode format, and it will<br>
        take some effort to maintain compatibility with the previous version.<br>
        Only add an instruction if it is absolutely necessary.<br></blockquote><div><br></div><div>The point of this is that we want to strongly encourage people to look for other solutions first... but on the other hand this isn't a blanket ban on new instructions; pushing intrinsics too far consistently caused trouble for exception handling in LLVM for years.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I need to think about it more, but, I am currently leaning toward the first<br>
option (with coro.fork and coro.end). The "f_inner" is still part of the f,<br>
but nicely delineated with corobegin and coro.end.<br>
<br>
  corobegin to label %coro.start<br>
         suspend label %retblock<br>
<br>
   corosuspend [final] [save %token] resume label %resume<br>
            cleanup label %cleanup<br>
<br>
    call void @llvm.coro.end();<br>
<br>
Does it look better?<br>
<span class=""></span></blockquote><div><br></div><div>Yes, that seems fine.  There's still the potential for non-initialization instructions sneaking into the initialization block, but you can probably handle it somehow.<br><br></div><div>That said, thinking about it a bit more, I'm not really sure why you need to tie the suspend call to the branch in the first place.  What exactly is your algorithm doing that requires it?  I mean, a naive implementation of CoroSplit based on your llvm.experimental.coro.suspend intrinsic clones the whole function, replaces the result of suspend calls with "true" in one version and "false" in the other, and runs SimplifyCFG to kill the dead code.  And even with a an algorithm that tries to be more clever, you probably need to do some cloning anyway: presumably frontends will want to share code between the destroy and unwinding codepaths.<br><br></div><div>-Eli<br></div></div></div></div>