[LLVMdev] RFC: Exception Handling Proposal II

[Renato Golin]

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