2017-06-02 19:51 GMT+08:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>:> On 2 Jun 2017, at 03:38, TONGARI J via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > > > I'm aware of the invoke instruction and landingpad. But it's too heavy > > weight for control flow. It's quite expensive to take the exceptional > path > > in C++. > > > > What I want is a more lightweight approach, to pass the return address to > > the callee, and let the callee jump to that address directly. > > The best way of implementing this is likely to be to use a custom calling > convention along with invoke. The invoke instruction will handle the > semantics correctly in the IR, but you’ll need to modify the back end to > understand that it should generate the call site differently and not emit > unwind tables. >A custom calling convention doesn't suffice, there could be more than one alternate paths. And invoke instruction is also not general enough. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170602/9a62f335/attachment.html>
David Chisnall via llvm-dev
2017-Jun-07 14:51 UTC
[llvm-dev] Function with multi return path?
On 2 Jun 2017, at 15:34, TONGARI J via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > 2017-06-02 19:51 GMT+08:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>: > On 2 Jun 2017, at 03:38, TONGARI J via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > I'm aware of the invoke instruction and landingpad. But it's too heavy > > weight for control flow. It's quite expensive to take the exceptional path > > in C++. > > > > What I want is a more lightweight approach, to pass the return address to > > the callee, and let the callee jump to that address directly. > > The best way of implementing this is likely to be to use a custom calling convention along with invoke. The invoke instruction will handle the semantics correctly in the IR, but you’ll need to modify the back end to understand that it should generate the call site differently and not emit unwind tables. > > A custom calling convention doesn't suffice, there could be more than one alternate paths. And invoke instruction is also not general enough.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. David
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>