similar to: [LLVMdev] Improvements to ExceptionHandling

Hi everyone, After some time hacking on llvm, let me introduce myself :) I'm a PhD student at the French university Pierre et Marie Curie in Paris. I work on a project called the "Virtual Virtual Machine" project. You can find some (dated) information on the website http://vvm.lip6.fr. Basically it's a "low level virtual machine" :) with a just in time compiler

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. Ciao, Duncan.

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

On Sep 6, 2009, at 10:52 AM, Bill Wendling wrote: > The problem he's facing here isn't necessarily one of correctness. > He's dealing with undefined behavior (at least in C code). There are > no guarantees that the compiler will retain a certain semantic > interpretation of an undefined construct between different versions of > the compiler, let alone different

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

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

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

On Thu, 5 Apr 2007, Nicolas Geoffray wrote: > On top of this execution environment we have implemented a java virtual > machine and a .net virtual machine. They > are both functional and we achieve reasonable performance (1/3 of IBM's > JVM or Mono). Cool. > This algorithm does not work with llvm because creating labels (which > correspond to creating basic blocks) does not

On Sun, Sep 6, 2009 at 3:22 PM, Chris Lattner<clattner at apple.com> wrote: > > On Sep 6, 2009, at 10:52 AM, Bill Wendling wrote: > >> The problem he's facing here isn't necessarily one of correctness. >> He's dealing with undefined behavior (at least in C code). There are >> no guarantees that the compiler will retain a certain semantic >>

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

On Sep 6, 2009, at 2:01 PM, Török Edwin wrote: > On 2009-09-06 20:52, Bill Wendling wrote: >> The problem he's facing here isn't necessarily one of correctness. >> He's dealing with undefined behavior (at least in C code). There are >> no guarantees that the compiler will retain a certain semantic >> interpretation of an undefined construct between different

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

Talin wrote: > Currently it states in the language manual that the results of division > by zero are undefined. However, I'm curious as to how you would normally > handle either divide by zero or other "hardware" exceptions (null > pointer dereference and so on) and turn them into LLVM exceptions. Ultimately, what we'd like to do is attach a bit to each

On 11-06-12 12:01 AM, Sohail Somani wrote: > Is LLVM expressive enough to represent asynchronous exceptions? > --------------------------------------------------------------- > > Summary: Need new LLVM instructions or extending of all instructions. > > C++ exceptions are synchronous: the compiler knows when/where they are > being raised. > > Asynchronous exceptions can

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

On Jun 12, 2011, at 11:24 PM, Bill Wendling wrote: > 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?

On Mon, 24 Apr 2006, Archie Cobbs wrote: > Related idea.. what if all instructions (not just "invoke") could be > allowed to have an optional "except label ..."? This is the direction that we plan to go, when someone is interested enough to implement it. There are some rough high-level notes about this idea here:

On 2009-09-06 20:52, Bill Wendling wrote: > The problem he's facing here isn't necessarily one of correctness. > He's dealing with undefined behavior (at least in C code). There are > no guarantees that the compiler will retain a certain semantic > interpretation of an undefined construct between different versions of > the compiler, let alone different

On Mon, Jun 13, 2011 at 2:56 PM, John McCall <rjmccall at apple.com> wrote: > On Jun 13, 2011, at 2:23 PM, Andrew Trick wrote: > > On Jun 13, 2011, at 12:29 AM, John McCall wrote: > > On Jun 12, 2011, at 11:24 PM, Bill Wendling wrote: > > 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,

Chris Lattner wrote: > On Mon, 24 Apr 2006, Archie Cobbs wrote: >> Related idea.. what if all instructions (not just "invoke") could be >> allowed to have an optional "except label ..."? > > This is the direction that we plan to go, when someone is interested > enough to implement it. There are some rough high-level notes about > this idea here: