[LLVMdev] RFC: Exception Handling Rewrite

Bill Wendling wendling at apple.com
Tue Aug 2 18:01:29 PDT 2011


On Aug 2, 2011, at 4:43 PM, John McCall wrote:

> 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
>>>>> functions.
>>>>> 
>>>> 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>   :=
>>>>>>      cleanup
>>>>>>   |  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*
> 
*smacks forehead* Duncan and John are exactly right with regards to filters. In my zeal today, I took out the code that would parse the 'filter' clause correctly. I'll add that back in and submit a corrected patch.

-bw





More information about the llvm-dev mailing list