[LLVMdev] RFC: Exception Handling Rewrite

[Peter Lawrence]

Andrew,
                 yes, my brain-bad, soon after I hit the Send button  
I realized it
is the InvokeInst that starts the lifetime of those hard-registers, not
the LandingpadInst, but you beat me to the reply.

-Peter Lawrence.


On Aug 4, 2011, at 4:16 PM, Andrew Trick wrote:

> 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/277ca8cf/attachment.html>