On Dec 2, 2010, at 4:45 AM, Duncan Sands wrote:>> I'm unhappy about how this bakes _Unwind_Resume into the backend, particularly >> since that prevents us from using better alternatives when they're available >> (e.g. the ARM EH ABI's _cxa_end_cleanup(), which saves code size by not requiring >> the exception pointer, but which we can only use if we're linking in the C++ standard >> library). > > the code generators can lower "unwind" to a call to _cxa_end_cleanup on that > platform.No, they can't, it's language-library-specific. Only the frontend knows whether it's safe to introduce that dependency. Also, _Unwind_Resume has a slightly different name in ARM sjlj EH; it would be great if codegen didn't have to hard-code all this again.>> One idea that comes to mind is that we could make Yet Another call-like instruction, >> a terminator like 'invoke' but with no successors and with the special >> replaced-with-a-branch behavior when inlined through an invoke. So the front-end >> could call whatever function it pleases, taking responsibility for passing in the right >> information. > > I think this is way too complicated.Then instead of using a call, it can be a special kind of unconditional branch which the inliner rewrites into a normal branch; that would look exactly like your "rewind" instruction except for having a successor. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101202/c2f3d11c/attachment.html>
Hi John,>>> I'm unhappy about how this bakes _Unwind_Resume into the backend, particularly >>> since that prevents us from using better alternatives when they're available >>> (e.g. the ARM EH ABI's _cxa_end_cleanup(), which saves code size by not requiring >>> the exception pointer, but which we can only use if we're linking in the C++ >>> standard >>> library). >> >> the code generators can lower "unwind" to a call to _cxa_end_cleanup on that >> platform. > > No, they can't, it's language-library-specific. Only the frontend knows whether > it's safe to > introduce that dependency.I guess the front-end can pass an option to the code generators to select the desired form.> Also, _Unwind_Resume has a slightly different name in ARM sjlj EH; it would be great > if codegen didn't have to hard-code all this again.If it was all in codegen then front-ends wouldn't have to have this logic.>>> One idea that comes to mind is that we could make Yet Another call-like >>> instruction, >>> a terminator like 'invoke' but with no successors and with the special >>> replaced-with-a-branch behavior when inlined through an invoke. So the front-end >>> could call whatever function it pleases, taking responsibility for passing in >>> the right >>> information. >> >> I think this is way too complicated. > > Then instead of using a call, it can be a special kind of unconditional branch which > the inliner rewrites into a normal branch; that would look exactly like your > "rewind" > instruction except for having a successor.Another possibility is to have front-ends output the desired library call, and stick an attribute "rewinds" on the call, which tells the optimizers that an invoke of this call is equivalent to a branch. Ciao, Duncan.
On Dec 2, 2010, at 12:32 PM, Duncan Sands wrote:>>> the code generators can lower "unwind" to a call to _cxa_end_cleanup on that >>> platform. >> >> No, they can't, it's language-library-specific. Only the frontend knows whether >> it's safe to >> introduce that dependency. > > I guess the front-end can pass an option to the code generators to select the > desired form. > >> Also, _Unwind_Resume has a slightly different name in ARM sjlj EH; it would be great >> if codegen didn't have to hard-code all this again. > > If it was all in codegen then front-ends wouldn't have to have this logic.If the front-end has to pass an option to the code generator to get the right unwinding function, then it still has to have the logic — it just acts on it in an unnecessarily obscure and constrained way. Also, we wouldn't be doing anyone any favors by hiding this. It's not like the current representation is some heavily-virtualized ideal which painlessly hides all these pesky details. Every front-end already hard-codes a dozen other details about how unwinding works on the target. The IR itself hard-codes multiple details of DWARF EH, like the type info table being global to a function, and like there being one entry point per instruction. Bill's proposal is actually much more virtualized than yours, as it hides both the selector value and the type info indices.>>>> One idea that comes to mind is that we could make Yet Another call-like >>>> instruction, >>>> a terminator like 'invoke' but with no successors and with the special >>>> replaced-with-a-branch behavior when inlined through an invoke. So the front-end >>>> could call whatever function it pleases, taking responsibility for passing in >>>> the right >>>> information. >>> >>> I think this is way too complicated. >> >> Then instead of using a call, it can be a special kind of unconditional branch which >> the inliner rewrites into a normal branch; that would look exactly like your >> "rewind" >> instruction except for having a successor. > > Another possibility is to have front-ends output the desired library call, and > stick an attribute "rewinds" on the call, which tells the optimizers that an > invoke of this call is equivalent to a branch.I think I prefer the special branch to the tagged call. It's actually semantically important that the optimizers not touch the call except during inlining. John.