[LLVMdev] RFC: Exception Handling Rewrite
wendling at apple.com
Sat Jul 23 01:11:27 PDT 2011
On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote:
> On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote:
>> // Restrictions:
>> There are several new invariants which will be enforced by the verifier:
>> 1. A landing pad block is a basic block which is the unwind destination of an
>> invoke instruction.
>> 2. A landing pad block must have a landingpad instruction as its first non-PHI
>> 3. The landingpad instruction must be the first non-PHI instruction in the
>> landing pad block.
>> 4. Like indirect branches, splitting the critical edge to a landing pad block
>> requires considerable care, and SplitCriticalEdge will refuse to do it.
>> 5. All landingpad instructions in a function must have the same personality
> Could we add:
> - A landing pad block is not the destination of any other kind of terminator. Only unwind edges are allowed.
> - The landingpad instruction must only appear at the top of a landing pad. It cannot appear in any other block, or following non-phi instructions.
Most of this is covered by 2&3. But it would be good to explicitly state that a landingpad instruction can appear only in a landing pad block.
> Why won't SplitCriticalEdge work for landing pads? Does it require more than splitting the landing pad after the landingpad instruction, and duplicating the top half? Alternatively, could we get a SplitLandingPad function?
Splitting a critical edge, especially in this case, isn't necessary for correctness. It's an optimization. In general, the use of a value in the catch blocks will access that value via memory. It also complicates the SplitCriticalEdge function, like you outlined.
> Will it be possible to split landing pads during codegen?
Split a landing pad or split the critical edges to a landing pad? If the former, then yes. You can also split a landing pad in LLVM IR. You just can't split the landing pad block before the landingpad instruction.
More information about the llvm-dev