[LLVMdev] RFC: Exception Handling Rewrite

[Bill Wendling]

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
>>   instruction.
>> 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
>>   function.
> 
> 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.

-bw