[LLVMdev] LLVM Exception Handling

[Nathan Jeffords]

On Sun, Sep 26, 2010 at 5:08 AM, Eugene Toder <eltoder at gmail.com> wrote:

> I may me wrong, but I think Nathan used ints for demonstration
> purposes only. unwind always takes i8* argument that ideally should be
> a pointer to exception structure, variable %x in invoke is also typed
> i8*, it's not "untyped". Probably more llvm-ish syntax would be
>
> unwind i8* %x to label %catch
>

> to show the type explicitly.
>

Yes, I didn't specify a type because %x is an assignment (like '%x = call
@eh.exception ...'). Admittedly this specify syntax is misleading. I think a
syntax like:

invoke i32 @v(i32 %o)
  success %s to label %ok
  unwind %x to label %catch

would be more consistent and have the benefit better indicating what value
is generated when branching to what label.

[snip]

Nathan -- is this approach simpler than using intrinsics @eh.throw
> (assuming it's added) and @eh.exception? The latter seems more
> flexible in supporting various levels of ABI (I think ideally LLVM
> exception handling should follow general platform ABI and also allow
> front-ends for specific languages generate code in accordance with
> language specific ABI).
>

I don't know the specifics of all the platforms that LLVM may run on so this
is a hard question to answer. I think looking at this as a representation
and not an implementation may help. If it is assumed that all exception
handling mechanisms fundamentally pass pointers to exception information
than this representation would work, and it would be lowered to
the appropriate platform specific representation by a platform specific
pass. Another approach (that should be selectable by the compiler) would be
for the code generator to lower this representation into what ever it would
take to pass the unwind pointer argument to the catch block referenced by
the invoke instruction to allow the compiler to be platform agnostic at the
cost of some flexibility with regards to the types of options available with
platform specific implementations. I do think that a direct representation
is more desirable than one implemented via intrinsics. I think that that
makes it easier for passes to deal with.


> I going with invoke instruction that returns exception pointer (which
> feels right to me) maybe this is a good candidate for using union type
> -- invoke can produce a single result which is either normal return
> value or an exception pointer, since only one of the two values can be
> actually produced. This sounds logical but may be taking us too far
> from ABIs.
>
>
This could work too if unions are going to be supported. Perhaps this could
be another reason why LLVM needs unions. I don't now any details on the
semantics of the existing union support, but for this purpose I think I can
see a set of semantics. It would revolve around have a way tie what field of
the union is valid to one or more basic blocks.

[snip]

Thanks for the feedback,

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