[LLVMdev] RFC: Exception Handling Rewrite

Bill Wendling wendling at apple.com
Fri Aug 5 14:23:53 PDT 2011


On Aug 5, 2011, at 1:43 PM, Bill Wendling wrote:

> On Aug 5, 2011, at 10:57 AM, Peter Lawrence wrote:
> 
>> Bill,
>>      ooops, yes, I described the meaning of "throw(A)" backwards,
> 
> I thought that might be the case. :)
> 
>> but I still
>> think my example shows why you cannot merge LandingpadInst while
>> inlining because multiple filter-lists on a LandingpadInst don't make sense.
>> 
>> Perhaps I'm reading your original spec wrong, perhaps I'm mis-reading
>> Duncan's emails, but I read them to mean that your syntax supports
>> multiple filter-lists on a single LandingpadInst.
>> 
>> first off, I think we agree on what I think you're saying below, that if foo calls
>> something, and bar calls somethingelse, and that if these have different
>> exception-specifications, then we can translate into different DWARF Action
>> and Types Tables, each call has it's own (in this case unique) Actions.
>> 
>> second, do you agree that if one exception-spec says to unexpected()
>> if anything other than 'A' is thrown, and another exception-spec says
>> to unexpected() if anything other than 'B' is thrown, that these cannot
>> be merged --> by that I mean they cannot have the same landingpad <-- ?
>> 
> Well, the only way they could be merged is through inlining. So I don't agree. One exception spec is encapsulated by the caller's exception spec. And merging them can be done even now. I give an example below.
> 
I guess more to the point, two landing pad instructions won't be 'merged' together except through inlining. It's true that two landing pad instructions with different filters may exist within the same function, but merging is not something that should happen via normal, non-inlining code motion.

-bw




More information about the llvm-dev mailing list