llvm dev - Jun 2011 - [LLVMdev] Is LLVM expressive enough to represent asynchronous exceptions?

On 11-06-12 7: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.
The CFG point is a valid point. In what I've read on the topic so far
(yay Internet), it seems like the CFG would have to represent the fact
that control can jump to a handler after nearly every instruction in the
presence of async exceptions. The Hotspot compiler probably does this.
Maybe Bill knows for sure?

If so, that is totally fine with me as I don't see any other option!

On Jun 12, 2011, at 5:31 PM, Sohail Somani wrote:
> On 11-06-12 7: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.
> 
> The CFG point is a valid point. In what I've read on the topic so far
> (yay Internet), it seems like the CFG would have to represent the fact
> that control can jump to a handler after nearly every instruction in the
> presence of async exceptions. The Hotspot compiler probably does this.
> Maybe Bill knows for sure?
Asynchronous exceptions in Java are cooperative:  execution isn't
necessarily interruptable at an arbitrary point.  I assume this is
represented internally in Hotspot's IR by ensuring that every code
sequence performs a synchronous check for async exceptions after
a bounded amount of computation completes.  By contrast,
asynchronous exceptions from, say, signal handlers are not
cooperative.

John.

On 11-06-12 8:53 PM, John McCall wrote:
>> > The CFG point is a valid point. In what I've read on the topic
so far
>> > (yay Internet), it seems like the CFG would have to represent the
fact
>> > that control can jump to a handler after nearly every instruction
in the
>> > presence of async exceptions. The Hotspot compiler probably does
this.
>> > Maybe Bill knows for sure?
>
> Asynchronous exceptions in Java are cooperative:  execution isn't
> necessarily interruptable at an arbitrary point.  I assume this is
> represented internally in Hotspot's IR by ensuring that every code
> sequence performs a synchronous check for async exceptions after
> a bounded amount of computation completes.  By contrast,
> asynchronous exceptions from, say, signal handlers are not
> cooperative.
This is true.

So how could you represent this in a CFG? Is it enough to assume that
signals can occur only after every instruction? Should you represent it
in a CFG?

What else can you do?!

Sorry, more questions than answers...

On Jun 12, 2011, at 5:53 PM, John McCall wrote:
> 
> On Jun 12, 2011, at 5:31 PM, Sohail Somani wrote:
> 
>> On 11-06-12 7: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.
>> 
>> The CFG point is a valid point. In what I've read on the topic so
far
>> (yay Internet), it seems like the CFG would have to represent the fact
>> that control can jump to a handler after nearly every instruction in
the
>> presence of async exceptions. The Hotspot compiler probably does this.
>> Maybe Bill knows for sure?
> 
> Asynchronous exceptions in Java are cooperative:  execution isn't
> necessarily interruptable at an arbitrary point.  I assume this is
> represented internally in Hotspot's IR by ensuring that every code
> sequence performs a synchronous check for async exceptions after
> a bounded amount of computation completes.  By contrast,
> asynchronous exceptions from, say, signal handlers are not
> cooperative.
> 
> John.
Yes. Thank you John for the perfect explanation.

Although I believe asynchronous signals are also best handled by the runtime.
They can be converted into cooperative exceptions. I have to say I can't see
the value in resuming from an interrupt at literally any instruction address.

-Andy