Hi Reid, 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170602/57f0571e/attachment.html>
David Chisnall via llvm-dev
2017-Jun-02 11:51 UTC
[llvm-dev] Function with multi return path?
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. David
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>