[LLVMdev] RFC: Exception Handling Rewrite

[Chris Lattner]

On Aug 1, 2011, at 11:13 PM, Bill Wendling wrote:
>>> The 'landingpad' instruction replaces the current 'llvm.eh.exception' and
>>> 'llvm.eh.selector' intrinsics.
>>> 
>>> // Syntax:
>>> 
>>>  %res = landingpad<somety>  personality<ty>  <pers_fn>  <clause>+
>>> 
>>> where
>>> 
>>>  <clause>  :=
>>>       cleanup
>>>    |  catch<ty_1>,<ty_2>, ...,<ty_n>
>>>    |  filter<ty_1>,<ty_2>, ...,<ty_m>
>>> 
>>> and the result has the type '<somety>'. The personality functions must be the
>>> same for all landingpad instructions in a given function.
>> 
>> 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.

>> Another comment is: rather than using a function pointer for the personality
>> function (and requiring a declaration for the personality), maybe it could
>> just be a string?  After all, you don't actually do anything much with it:
>> you just dump the name into the assembler.  Perhaps the same goes for catches
>> and so on: is a global really needed and not its name?
>> 
> I'm hesitant to do this because the machinery for printing out the correct global value's representation in assembly is already in the code.

IMO, it is clearly the right thing to have a GV here instead of a string.

>> Finally, rather than baking cleanups, filters etc into the IR, I suppose the
>> landingpad instruction could just be:
>> 
>> %res = landingpad<some type> data<ty>
>> 
>> For standard setups "data" could be a struct type, with fields for the
>> personality function, a cleanup flag, lists of catches and filters and so on.
>> 
> True, but this makes the IR less readable for me. I would have to look at a global to understand what this instruction is doing. Plus, we have problems with the "funky personality function" situation. With the proposal, we can interleave the clauses. With the 'data' option, we would have to have a non-IR way of interpreting the struct. So we're kind of back to the situation we have with the intrinsics...

I agree with Bill in this case.  The reason for landingpad to be an instruction is a) make it clear that it is magic in several ways (e.g. pinned to the start of a block), and b) so that LandingPadInst can have a bunch of useful accessors on it.

-Chris