[LLVMdev] RFC: Exception Handling Proposal II

[Nick Kledzik]

On Nov 30, 2010, at 11:53 PM, Duncan Sands wrote:
>> Just to throw out another perspective, I've wondered about optimizations we could do if we designed a new personality function.  In particular, I'd like to eliminate the use of landing pads for destructing locals.  Instead the LSDA would encode the pc liveness ranges of local objects, their location in the stack frame, and their destructor functions.  Then the new personality function would iterator through the LSDA and call the appropriate destructors.  The upshot is that functions will be smaller (no landing pad code) and there would be no landing pads in the bitcode (except for catch clauses).   This is better aligned with the "zero cost" (if not used) exception model then what we currently have.
>> 
>> There are a number of details to work out in having the personality function run destructors, but such a model would change how we design EH information into the bitcode.
>> 
>> I have not looked at the existing LSDA information in detail, but it should also be possible to still use the existing personality function even with bitcode targeting the new model.  Basically, we'd need a pass that would append snippets of code to the end of the function (which are the landing pads needed by the existing personality function), and update the LSDA to reference those landing pads with the pc ranges needed for cleanups.
> 
> if I understand your suggestion right, this would stop destructors from being
> inlined, which is often a win (eg if the destructor is the empty function).
Yes.  But inlining away empty destructors is a win when you have to codegen landing pads.  When there are no landing pads, the only cost is some extra LSDA entries which will only ever be accessed if an exception is thrown.  And it may be possible to detect empty destructors and optimize away those entries.

-Nick