[LLVMdev] RFC: Exception Handling Rewrite

Peter Lawrence peterl95124 at sbcglobal.net
Thu Aug 4 16:04:00 PDT 2011


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


More information about the llvm-dev mailing list