[LLVMdev] LLVM Exception Handling

[Nathan Jeffords]

On Sun, Sep 26, 2010 at 11:27 AM, Renato Golin <rengolin at systemcall.org>wrote:

> On 26 September 2010 18:56, Nathan Jeffords <blunted2night at gmail.com>
> wrote:
> > The syntax for the invoke instruction is a little misleading. %x is a
> value
> > that is being generated by the instruction, not passed to is. It is no
> > different in that regard as to say '%x = call @eh.exception ...'. Since
> you
> > don't specify the type in that type of assignment, I chose not to here
> > either.
>
> I see, you're saving a call to @llvm.eh.exception in the IR. But is
> that really necessary?
>
> I mean, if you're using sj/lj you can always optimize them away if not
> using, but on dwarf exceptions that is really a bonus. Several invokes
> can unwind to a single landing pad, so it makes more sense to put the
> call on the landing pad, because it is there that the exception
> structure is going to be used.
>
> Nevertheless, the docs say having the eh.exception in the landing pad
> is actually a limitation of the IR, but I honestly don't know what
> that limitation is. That could be what you're trying to fix, but I can
> only see that it'll be better for sj/lj, I can't see how that's better
> for dwarf exceptions.
>
>
I believe the perceived problem with using eh.exception is that
is disassociates the source of the value with the invoke instruction that
generated it. As far as reusing the landing pad, that is still possible, it
would just require a phi node in the landing pad to bring all the different
exception values together into one that could be processed by the exception
handling code.


>
> > I agree; this change is not attempting to change how exception handling
> > works, just provide a small change in how it is represented in the IR to
> > make it more direct. Especially for users not using gcc/dwarf exception
> > handling (I hope to attempt an SEH implementation)
>
> I agree that it's simpler for sj/lj, but you have to be careful not to
> break the dwarf contract between the three parties: eh-lib, eh-tables
> and try/catch blocks. It is really tricky to make sure that contract
> is working, the easiest being having a huge test codebase to run
> before/after your changes and the surest having Knuth to prove it's
> right. ;)
>
> Whatever your changes are, just remember that the syntax has to make
> sense for dwarf EH users as well. Removing clutter from sj/lj and
> introducing it to dwarf is no gain.
>
>
Once again, I fully agree, and I think that this approach changes nothing
semantically about how dwarf exception handling works.


> --
> cheers,
> --renato
>
> http://systemcall.org/
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
>


I will continue my response in your next message.

-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100926/4e9c68b7/attachment.html>