<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-06-07 23:42 GMT+08:00 David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">No, but you can take the address of the block, pass it to the function, have the function return to the alternate return address and then (in the caller) jump immediately to the address in the return register.</blockquote><div><br></div><div>Yeah, that's the closest way we can get in LLVM at this moment.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Note that this (along with your original suggestion) will have really poor interaction with any modern branch predictor.<br></blockquote><div> </div><div>In my idea the caller and callee have full knowledge about the branch destinations, so if the optimizer inlines the callee, it can jump to the alternate destinations w/o indirection.<br></div><div>In case it's not inlined, the normal return path should incur no overhead as well, and for alternate return paths it's just a matter of setting the return register.</div><div>But as I said, I'm not an expert so I don't really know whether what I described is implementable in LLVM on all architectures.</div><div><br></div></div></div></div>