[LLVMdev] LLVM Exception Handling

[Renato Golin]

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 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.

-- 
cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm