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?> - 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.How does this differ from 2&3 above? Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110722/b74adfc4/attachment.html>
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 landingpad instruction must only appear at the top of a landing pad. It cannot appear in any other block, or following non-phi instructions. > > How does this differ from 2&3 above?It probably doesn't, it wasn't completely clear to me. /jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110723/c982509e/attachment.html>
On Jul 23, 2011, at 12:26 AM, Jakob Stoklund Olesen wrote:> SjLj is weird. How do we pass values along unwind edges today? Don't they need to dominate the setjmp call?We pass them through memory: // If we decided we need a spill, do it. // FIXME: Spilling this way is overkill, as it forces all uses of // the value to be reloaded from the stack slot, even those that aren't // in the unwind blocks. We should be more selective. if (NeedsSpill) { ++NumSpilled; DemoteRegToStack(*Inst, true); } So after SjLjEHPrepare, the invokes should probably be turned into calls and the unwind edges removed. The unwind edges don't represent control flow anymore, and they are not needed for dominance. They are only used for: // We still want this to look like an invoke so we emit the LSDA properly, // so we don't transform the invoke into a call here. It is possible we could feed all of them to a dummy landing pad that then branches to setjmp's second return? /jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110723/7ef5e71b/attachment.html>
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