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

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

On Jun 13, 2011, at 2:12 PM, Andrew Trick wrote:
> 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.
For what it's worth, SEH (which inspires a lot of this) allows blocks of
code to be protected from interruption.

But yes, I am not inclined to support asynchronous exceptions from signals.

John.

On 13 June 2011 22:27, John McCall <rjmccall at apple.com>
wrote:
> But yes, I am not inclined to support asynchronous exceptions from signals.
Ah, ok. I was beginning to wonder... ;)

--renato

Hi John,

On 13/06/11 23:27, John McCall wrote:
> On Jun 13, 2011, at 2:12 PM, Andrew Trick wrote:
>> 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.
>
> For what it's worth, SEH (which inspires a lot of this) allows blocks
of code to be protected from interruption.
>
> But yes, I am not inclined to support asynchronous exceptions from signals.
gcc Ada turns signals into exceptions.  As far as I know it does this
completely asynchronously, and the fact that LLVM doesn't support this
is rather bad as far as Ada is concerned.  That said, the Ada front-end
doesn't rely on this for things like dividing by zero: it precedes all
code that does division by a bunch of checks that test that nothing can
go wrong (like dividing by zero) and explicitly raises a "synchronous"
exception if one of the checks fail.  In particular it does not rely on
-ftrapv to catch integer overflow (which must raise an exception); I hear
that this is because -ftrapv does not work reliably.  I'm assuming that it
explicitly checks for division by zero because relying on signals does not
work reliably, e.g. Ada semantics are not always preserved by the optimizers
if you do this; but I'm not sure.  So when does Ada use signals? 
Essentially
never!  I.e. an Ada program only gets hit by a signal if something very bad
went wrong, that the compiler couldn't catch by inserting explicit checks.
This almost always means memory corruption: for example a double free or a
use after free can result in the program being hit by a signal, which then
gets turned into an exception.  Since the Ada language treats these kinds of
things as "unbounded errors" (i.e. the nasal demon sort), there are no
special
semantics to preserve, so relying on signals is presumably fine.  Things like
dividing by zero are "bounded errors" (i.e. the consequences of this
kind of
error are carefully circumscribed), which is presumably why the compiler is
very careful that Ada semantics are preserved in these cases.

Ciao, Duncan.