[LLVMdev] RFC: Exception Handling Rewrite
baldrick at free.fr
Sun Jul 31 11:06:22 PDT 2011
> Please read this proposal and send me your comments, suggestions, and concerns.
this proposal looks great to me. Thanks for working on it. I have a few minor
comments, see below.
> // The 'landingpad' Instruction
> The 'landingpad' instruction replaces the current 'llvm.eh.exception' and
> 'llvm.eh.selector' intrinsics.
> // Syntax:
> %res = landingpad<somety> personality<ty> <pers_fn> <clause>+
> <clause> :=
> | 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
Also, there isn't much point to having multiple "cleanup" entries, but I
guess it makes things more regular to allow it, and perhaps custom personality
functions might want to do something special.
If there is only a cleanup, the personality function doesn't really matter
because all standard personality functions treat cleanups the same way. GCC
has an optimization in which you don't have to specify a personality function
in this case (when it comes to codegen time, if there is some personality
function floating around, it uses that; if not it uses the C personality
function; when inlining into something with a catch clause, the personality
function from the catch is used etc).
Something like this could be nice for LLVM too. For example the LLVM garbage
collector codegen code wants to insert a simple cleanup: run some cleanup code
then resume. It would be nice if it didn't have to specify a personality. For
example by using the null pointer for the personality function. That said I
suppose such code could be required to specify (eg) the C personality function.
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?
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.
> 5. All landingpad instructions in a function must have the same personality
And presumably the same type.
More information about the llvm-dev