[LLVMdev] An alternate implementation of exceptions

Duncan Sands baldrick at free.fr
Fri Sep 4 00:39:50 PDT 2009

Hi Mikael, the idea of modifying functions so they return two parameters
(the usual one and an exception pointer or some kind of exception flag)
is well known.  The LLVM vmkit project actually uses a variant of this:
rather than returning the exception pointer in a register, it sticks it
in a global thread local variable.

I only took a quick look at your paper, but it seems to me that it has
a serious problem: you can't link C code using your exception handling
mechanism with C code compiled using another compiler, since the carry
flag may not be cleared on function return by the code compiled by the
other compiler.  Perhaps you addressed this issue in your paper, as I
mentioned I only glanced at it.  Vmkit doesn't suffer from this problem,
since only code that is aware of vmkit exceptions will store in the

Also, I don't see the point of the carry flag.  Why don't you just
return the exception pointer in another register?  If it is non-null
then an exception was raised.  Are you trying to avoid register
pressure or save a cycle or two?

Finally, you could implement this (or something close to it) pretty
easily in LLVM.  Suppose you have a function "int f(params) {...}".
Rather than outputting this to LLVM IR as
   define i32 @f(params) { ... }
you output it as
   define {i32, i8*} @f(params) { ... }
The additional return value is the exception pointer, which callers
can then inspect to see whether an exception was raised.  On x86-64
codegen will return the i32 in RAX and the exception pointer in RDX.



More information about the llvm-dev mailing list