[LLVMdev] RFC: Exception Handling Rewrite
rjmccall at apple.com
Tue Aug 2 18:43:24 CDT 2011
On Aug 2, 2011, at 10:28 AM, Duncan Sands wrote:
>>>> Is it intended that "cleanup ty_1, ty_2" potentially be different to
>>>> "cleanup ty_1 cleanup ty_2"? Perhaps this is useful for funky personality
>>> Yeah. One can basically interleave the catches and filters. But having two catch or two filter clauses in a row should be semantically the same as the clauses being merged into one. (E.g., your examples would be equivalent.)
>> Let me rephrase the question then. Why not make the grammar be either:
>>>>> <clause> :=
>>>>> | catch<ty_1>
>>>>> | filter<ty_1>
>> .. forcing "catch" or "filter" before each entry. If you don't like that, why not make the grammar be something like:
>>>>> %res = landingpad<somety> personality<ty> <pers_fn> (catch<ty>+)? (filter<ty>+)?
>> Is there anything specific about the ordering of catch or filter clauses that affect semantics? If so, the first alternative seems cleaner. If not, the second does.
> yes there is something about the order :) When front-ends output code, all
> catches come before filters, but after inlining you can get: catches, filters,
> catches, filters etc and this ordering needs to be preserved. Also, filters
> are different from catches: filter ty_1, ty_2, ..., ty_N matches any exception
> that would not be caught by any of ty_1, ty_2, ..., ty_N. This is quite
> different to filter ty_1, filter ty_2, ..., filter ty_N. For example, suppose
> you throw ty_2. Then the filter ty_1, ty_2, ..., ty_N wouldn't match that,
> but filter ty_1 would.
> So filter ty_1, ..., ty_N makes sense; but I don't think catch ty_1, ..., ty_N
> makes sense.
Agreed. Other notes: a zero-type filter is meaningful (and pretty
common — it's the result of 'throw()'), but the ordering of the cleanup
bit is not, so I would suggest this grammar:
Instruction ::= 'landingpad' Type 'personality' TypeAndValue 'cleanup'? LandingPadClause*
LandingPadClause ::= 'catch' TypeAndValue
LandingPadClause ::= 'filter' TypeAndValue*
More information about the LLVMdev