2017-06-07 22:51 GMT+08:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>:> > You could approximate this using the address-of-label extension and > passing the address of the return basic block to the function then, in the > abnormal return path, jumping to that. Doing anything else is likely to be > very complicated because the live registers at all of the potential landing > points will need to agree and you’re likely to cost more in code complexity > than you save. >I don't think blockaddress/indirectbr supports non-local jump. Does it? Or do you mean something else? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170607/b0d32031/attachment.html>
David Chisnall via llvm-dev
2017-Jun-07 15:42 UTC
[llvm-dev] Function with multi return path?
On 7 Jun 2017, at 16:13, TONGARI J via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > 2017-06-07 22:51 GMT+08:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>: > You could approximate this using the address-of-label extension and passing the address of the return basic block to the function then, in the abnormal return path, jumping to that. Doing anything else is likely to be very complicated because the live registers at all of the potential landing points will need to agree and you’re likely to cost more in code complexity than you save. > > I don't think blockaddress/indirectbr supports non-local jump. Does it?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. Note that this (along with your original suggestion) will have really poor interaction with any modern branch predictor. David
2017-06-07 23:42 GMT+08:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>:> > 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.Yeah, that's the closest way we can get in LLVM at this moment.> Note that this (along with your original suggestion) will have really poor > interaction with any modern branch predictor. >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. 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. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170608/6a331c31/attachment.html>