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

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.

Cameron

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.

-bw

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.

John.

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?

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 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.
> 
Placing the EH information on the basic block has the same implications for the
CFG for both questions. Namely, you are no longer representing the actual
control flow of the program.

-bw

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.

Adding proper support for SEH would complicate things. If you only allow extra
edges for asynchronous exceptions to be down edges in the (ordinary) dominator
tree, then at least the standard CFG traversals will continue to visit
instructions in dominance order. However, you still have to modify dominance
queries to take these extra edges into account.

Cameron