[LLVMdev] RFC: Exception Handling Rewrite

[Jakob Stoklund Olesen]

On Aug 5, 2011, at 10:57 AM, Peter Lawrence wrote:

> Guys,
>            on second thought...
> 
> doesn't making the exception registers live from the InvokeInst to the LandingpadInst
> create problems for critical-edge-splitting ?
> 
> if a landingpad-edge is critical and needs to be split, won't we be creating and inserting
> a new BB between the "invoke-block" and the "landingpad-block", and if we do then
> isn't there the possibility of the register allocator spilling the contents of the exception
> registers from within the newly created block --- but this block won't ever get executed
> because the _Unwind_ / _personality_ functions will cause control flow to go directly
> to the block with the LandingpadInst ?   If you really want to split a landingpad-edge
> won't you have to move the LandingpadInst up into the new block  ?

You cannot split critical edges to landing pads, but you can duplicate landing pads and distribute the predecessors any way you like.

The requirement is that all unwind edges go to landing pads and all non-unwind edges go to non-landing pads. That will also be required in the code generator.

> if this is true (and I seem to be making a lot of logic errors lately, so maybe reread and
> proof-read the above a few times...!...) then don't we need to add another invariant to
> Bill's list:
> 
> *) there can be no code between an InvokeInst and its LandingpadInst other than
> possibly PHINodes at the beginning of the landingpad-block.

I think this covers it:
A landing pad block must have a 'landingpad' instruction as its first non-PHI instruction.
There can be only one 'landingpad' instruction within the landing pad block.
A basic block that is not a landing pad block may not include a 'landingpad' instruction.
/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110805/69a05c77/attachment.html>