[LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?

[Jakob Stoklund Olesen]

On Jun 13, 2011, at 10:50 AM, John McCall wrote:

> On Jun 13, 2011, at 10:30 AM, Jakob Stoklund Olesen wrote:
>> The try block would look something like:
>> 
>> call _malloc
>> movq %rax, p(%rpb)
>> 
>> If you take an exception between those two instructions, you are leaking memory.
> 
> This is primarily an argument that C is not a good language to write async-exceptions-safe code in.  Java has similar potential races with async exceptions for non-memory resources that are cleaned up with finally blocks.
> 
> Note that the IR actually has sufficient information for this if optimization is on;  you'd just need completely ridiculous "where is this value at this specific instruction" logic in order to actually do the cleanup. :)  But that's actually doable with DWARF....

I agree with 'doable' and 'ridiculous' ;-)

> Again, I tend to agree that there are fundamental semantics problems with async exceptions, and I am not trying to argue that we should tackle them.

Right. I agree that we would need EH edges on basic blocks to deal with async exceptions. It would also require a completely different way of dealing with exceptions in the optimizers and code generators.

Synchronous exceptions are a completely different thing as you pointed out. They can be modeled with an explicit CFG, or with special EH edges on basic blocks.

The explicit CFG forces the ordering of trapping instructions. Something that may not be a language requirement?

/jakob