[LLVMdev] Alternative exception handling proposal
John McCall
rjmccall at apple.com
Thu Dec 2 15:59:30 PST 2010
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.
More information about the llvm-dev
mailing list