Chuan Qiu via llvm-dev
2017-Aug-07 17:49 UTC
[llvm-dev] Advise to implement return barriar
Hi llvm-dev, I'm trying to build a managed language that requires function call with return barrier using LLVM IR. During execution of a function call, if a special event during the call happens, it will overwrite the return address in the stack frame to another block, then continue the execution in the original function until it's actually returned, then execute a different block. It will be equivalent to the following pseudo code: flag, X = doSomeCall() if (!flag) { use1: // something use X } else { use2: // something else use X } While I'd like to make the flag implicit by changing the return address in stack frame from use1 to use2 and duplicate the post-call part, because such flag check could be added to almost every call site for my language and the probability returning other branch will be extremely unlikely. May I get some advise on how to implement the return barrier like this, even just locally? Introducing a new type of invoke inst that allows 2 normal destinations plus 2 unwind destination seems too much changes to make. Currently, I'm trying to add a new intrinsic IMPLICIT_FORK that returns a bool that can be used for conditional branch to introduce an extra successor in IR without emitting an code to trick the CFG passes, and that successor block must start with another intrinsic call CONTINUE which continues the call: it just emit a NOP but returns the value, and PC for the NOP will be stored by some global metadata value so the runtime knows which is the new PC value to overwrite, and address of NOP inst can still be used to unwind the stack properly. I've also tried using a general trampoline to be new return address, and based on return value from calling convention to record the return value, and throw an exception to go back to original method. Cheers Chuan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170807/17f15feb/attachment.html>
Jeremy Lakeman via llvm-dev
2017-Aug-08 11:40 UTC
[llvm-dev] Advise to implement return barriar
Something like this recent conversation? http://llvm.1065342.n5.nabble.com/llvm-dev-RE-Function-with-multi-return-path-td109752.html On Tue, Aug 8, 2017 at 3:19 AM, Chuan Qiu via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi llvm-dev, > I'm trying to build a managed language that requires function call with > return barrier using LLVM IR. > > During execution of a function call, if a special event during the call > happens, it will overwrite the return address in the stack frame to another > block, then continue the execution in the original function until it's > actually returned, then execute a different block. > > It will be equivalent to the following pseudo code: > > flag, X = doSomeCall() > if (!flag) { > use1: > // something use X > } else { > use2: > // something else use X > } > > While I'd like to make the flag implicit by changing the return address in > stack frame from use1 to use2 and duplicate the post-call part, because > such flag check could be added to almost every call site for my language > and the probability returning other branch will be extremely unlikely. > > May I get some advise on how to implement the return barrier like this, > even just locally? > > Introducing a new type of invoke inst that allows 2 normal destinations > plus 2 unwind destination seems too much changes to make. > > Currently, I'm trying to add a new intrinsic IMPLICIT_FORK that returns a > bool that can be used for conditional branch to introduce an extra > successor in IR without emitting an code to trick the CFG passes, and that > successor block must start with another intrinsic call CONTINUE which > continues the call: it just emit a NOP but returns the value, and PC for > the NOP will be stored by some global metadata value so the runtime knows > which is the new PC value to overwrite, and address of NOP inst can still > be used to unwind the stack properly. > > I've also tried using a general trampoline to be new return address, and > based on return value from calling convention to record the return value, > and throw an exception to go back to original method. > > Cheers > Chuan > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170808/885100b3/attachment.html>