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

[John McCall]

On Jun 13, 2011, at 12:53 AM, Cameron Zwarich wrote:

> On 2011-06-12, at 4:40 PM, John McCall wrote:
> 
>> On Jun 12, 2011, at 2:14 PM, Cameron Zwarich 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).
>> 
>> You and Bill seem to be responding to a different question, namely "Is LLVM expressive enough to represent synchronous exceptions from non-call instructions?"  This really has nothing to do with Sohail's question.  Duncan is quite correct:  the only reasonable representation for asynchronous exceptions is to attach EH information to basic blocks.
> 
> I was just commenting on the reference to Chris' original proposal to allow for non-terminators that throw (synchronous) exceptions. I don't think it is a good tradeoff.

Right, I'm still undecided about that.

Since there's been confusion about this in the past, I should clarify:  I am not trying to argue for or against these features.  I am trying to figure out what people actually want from our EH system, and to make sure people understand what each option requires.  Like you said, there are reasonable models for async exceptions, but they definitely complicate the CFG in some ways.

John.