[LLVMdev] RFC: Exception Handling Rewrite

[Andrew Trick]

Hi Peter,

Thanks for pointing this out. Some us who are concerned with codegen have discussed the problem. Although the details aren't decided, you can be sure that at the MachineInstr level we won't have a landindpadInst to model liveness of exception values. Any physical registers set by the personality function will be considered live immediately after the call on the unwind path.

-Andy

On Aug 4, 2011, at 4:04 PM, Peter Lawrence wrote:

> Chris,
>            it is goodness that the LandingpadInst will be pinned to the beginning
> of a BasicBlock,...  except for the possibility of PHINode instructions that _must_
> come even earlier.?.
> 
> I can't exactly put my finger on what's going to go wrong with this, 
> but it sure smells fishy...
> 
> 
> my current understanding is that the LandingpadInst will "define" some hard
> registers which will be used by following code to switch to the corresponding
> catch-clause
> 
> the lifetimes of these hard registers ostensibly starts at the LandingpadInst,
> but for purposes of PHI lowering and Register Allocation they _must_ actually
> start at the beginning of the BasicBlock -- since that is where control flow will
> return to from the _Unwind_RaiseException / __gcc_personality_v0 calls,
> and it is the _Unwind_ and _personality_ functions that physically set those
> hard registers, not the "LandingpadInst".
> 
> Somehow PHI lowering and register allocation need to be prohibited from
> using those hard registers for spill code at the beginning of a "landing pad block",
> but I don't see how that will "fall out" of the current design.?.
> 
> 
> 
> -Peter Lawrence.
> 
> 
> 
> 
> On Aug 3, 2011, at 12:35 AM, llvmdev-request at cs.uiuc.edu wrote:
> 
>> 
>> I agree with Bill in this case.  The reason for landingpad to be an instruction is a) make it clear that it is magic in several ways (e.g. pinned to the start of a block), and b) so that LandingPadInst can have a bunch of useful accessors on it.
>> 
>> -Chris
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110804/25a9e337/attachment.html>