[LLVMdev] RFC: Exception Handling Rewrite

[Bill Wendling]

On Jul 23, 2011, at 12:26 AM, Jakob Stoklund Olesen wrote:

> On Jul 22, 2011, at 11:52 PM, Cameron Zwarich wrote:
> 
>> 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.
>> 
>> How do we lower SjLj exceptions as an IR -> IR pass then?
> 
> I don't know. What does the landingpad instruction return when you branch to a landing pad?
> 
> A landing pad must follow some ABI convention, it represents the other return value of an invoke instruction.
> 
> SjLj is weird. How do we pass values along unwind edges today? Don't they need to dominate the setjmp call?
> 
The personality function sets the frame pointer (r7) and stores the value of which call has the exception onto the stack (the program stores the call's value onto the stack before each call is made...making it very efficient, of course). All of that stuff is done away from the landing pad blocks. More precisely, the personality function reenters the function after the setjmp (like you would expect). It then goes to a jump table, where it reads the value the personality function stored and jumps to the correct place via a jump table. We currently keep the llvm.eh.selector calls around so that CodeGen will be able to gather the exception handling information from it. But otherwise, it doesn't look like its used. It's all pretty gross.

-bw