[LLVMdev] RFC: Exception Handling Proposal II

[Eric Schweitz]

Are you suggesting having different semantics for different chunks of the IR
graph?

--
Eric

On Thu, Nov 25, 2010 at 2:33 AM, Renato Golin <rengolin at systemcall.org>wrote:

> On 25 November 2010 07:51, Duncan Sands <baldrick at free.fr> wrote:
> > If you got to XYZ because an instruction threw an exception before %x was
> > defined, then in XYZ you are using %x which was never defined.  In effect
> > the definition of %x in bb does not dominate the use in XYZ.  I think the
> > solution is to say that in XYZ you are not allowed to use any values
> defined
> > in bb: in the dominator tree, bb is not considered to dominate XYZ.
>
> Hi Duncan,
>
> I don't see how you can have dominance between a normal block and a
> cleanup block. Clean-up landing pads should never use user code (since
> they don't exist in userland).
>
> Catch landing pads, on the other hand, have the same dominance
> relationship that the rest of user code has (and the same problems).
>
> Since you should never branch to XYZ under normal circumstances, you
> should never rely on its predecessor's values anyway. That's the whole
> point of having @llvm.eh.exception and @llvm.eh.selector, as it's the
> role of the personality routine to pass information between the user
> code and unwinding code.
>
> In essence, in compiler generated landing pads, you should never
> generate a use of user values. But if XYZ is user code, it's user
> problem. ;)
>
> cheers,
> --renato
>
> PS: abnormal cases like throwing on a destructor when previously
> thrown inside a constructor leads to termination, so even if you "use"
> the value in the catch area, you won't get there anyway. ;)
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101127/e831a431/attachment.html>