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

[Sohail Somani]

On 11-06-12 6:13 PM, Bill Wendling wrote:
> On Jun 12, 2011, at 2:14 PM, Cameron Zwarich <zwarich at apple.com> wrote:
> 
>> On Jun 12, 2011, at 1:25 AM, Duncan Sands wrote:
>>
>>> Hi Sohail,
>>>
>>>> Is LLVM expressive enough to represent asynchronous exceptions?
>>>
>>> not currently.  The first step in this direction is to get rid of the invoke
>>> instruction and attach exception handling information to basic blocks.  See
>>> http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt
>>> for a discussion.
>>
>> Is this really a good idea? Why have a control flow graph if it doesn't actually capture control flow? There are lots of compilers for languages with more pervasive exceptions that represent them explicitly, e.g. the Hotspot server compiler for Java or several ML compilers (where integer overflow throws an exception). I can't see many advantages of implicit exceptions besides a nicer looking IR dump.
>>
> Andy expressed a similar concern to me when I asked him about it. (He previously worked on a Java compiler.) I'm inclined to agree with him. Especially considering that we run into large problems with 'use before definition' in such a model. 

For what it's worth, if you look at JVM assembler, it avoids the 'use
before definition' problem by defining all handlers after the regular
function body. These handlers are not referenced except in the exception
table.

So it must be implicit if it is represented at all. That is, some magic
adds in the equivalent of "to label %whatever unwind label %unwind".

Personally, I'd prefer a clean IR to write. I don't see anything wrong
with dumping the whole mess though.

So I think that just because it is not explicit in every instruction,
does not mean that the CFG won't capture it. The devil is in the
details, I'm sure.

Is Andy on this list and would he chime in with how to represent
asynchronous exceptions in a CFG?