On Nov 29, 2010, at 12:17 AM, Duncan Sands wrote:>> This is well-formed SSA; the alloca instruction %x is in the entry block and thus dominates both the store in %try and the load in %catch... > > this brings up the question of whether we should allow a catch handler to be > attached to the entry block. My feeling is that it should be disallowed. If > it was allowed then values defined in the entry block (like alloca's) would no > longer be guaranteed to dominate every other block in the function.Agreed. John.
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. -Nick
Hi Nick,> 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). Ciao, Duncan.