llvm dev - Jun 2017 - Function with multi return path?

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>

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>