similar to: [LLVMdev] Exception handling

I have a question concerning the exception handling tables that we generate. Right now we generate call sites for all of the code in a function, even for code that cannot (or at least shouldn't) throw an exception. E.g., for this code: #include <cstdio> struct Cleanup { ~Cleanup(void) { printf("in cleanup\n"); } }; static void inline_me(void) {

On 26 September 2010 13:08, Eugene Toder <eltoder at gmail.com> wrote: >  %s = invoke i32 @v(i32 %o) to label %ok >                   unwind %x to label %catch > ok: >  ret i32 %s > > catch: >  %type = call i32 @exception_type(i8* %x) >  %r = icmp eq i32 %type, 255 ; 255 is DivisionByZeroException type >  br i1 %r, label %bad, label %worse > > bad: >  ret

2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Hi James, > > Looking at: > > %7 = invoke i8* (...)* bitcast (i32 (%struct._Unwind_Exception*)* > @_Unwind_RaiseException to i8* (...)*)(i64* %6) > to label %8 unwind label %.finally_pad ; <i8*> [#uses=0] > > I am not sure this is going to work, at least from the way I've played with >

On Dec 1, 2010, at 12:55 AM, Sebastian Redl wrote: > On 01.12.2010 09:25, John McCall wrote: >> >> One problem I foresee is that it's possible for a dispatch block to become unreachable from its landing pad. If that block is then deleted, we'd lose information about what's supposed to unwind there. This could happen if, e.g., someone had a noreturn destructor. In

Hi Bill, > Right now we generate call sites for all of the code in a function, > even for code that cannot (or at least shouldn't) throw an exception. ... > (assume it's all been inlined), the EH handling table for "main" goes > from Leh_func_begin1 to Leh_func_end1, marking off each region whether > it can throw or not. From my reading of the Exception

On Dec 1, 2010, at 1:14 AM, John McCall wrote: > On Dec 1, 2010, at 12:55 AM, Sebastian Redl wrote: > >> On 01.12.2010 09:25, John McCall wrote: >>> >>> One problem I foresee is that it's possible for a dispatch block to become unreachable from its landing pad. If that block is then deleted, we'd lose information about what's supposed to unwind there.

The poor interaction between exception handling and inlining in LLVM is one of the main motivations for the new exception handling models proposed recently. Here I give my analysis of the origin of the problem in the hope of clarifying the situation. Soon after dwarf exception handling was implemented in LLVM, I noticed that some programs would fail when compiled at -O3, for example the

On 01.12.2010 09:25, John McCall wrote: > > One problem I foresee is that it's possible for a dispatch block to become unreachable from its landing pad. If that block is then deleted, we'd lose information about what's supposed to unwind there. This could happen if, e.g., someone had a noreturn destructor. In languages that usefully allow throws from EH destructors (i.e. Ada)

Hi Renato, > On 25 November 2010 07:51, Duncan Sands<baldrick at free.fr> wrote: >> If you got to XYZ because an instruction threw an exception before %x was >> defined, then in XYZ you are using %x which was never defined. In effect >> the definition of %x in bb does not dominate the use in XYZ. I think the >> solution is to say that in XYZ you are not allowed

On 25 November 2010 11:03, Duncan Sands <baldrick at free.fr> wrote: > I don't understand what you are saying.  Cleanups (e.g. destructors) Hi Duncan, Cleanup landing pads normally call destructors, but they're not a destructor themselves. I'm simply saying that compiler generated blocks (such as cleanups) should never depend on user variables. But I get what you're

I've read and re-read the LLVM exception handling doc, and there are a number of things that aren't clear to me. In the section describing llvm.eh.exception, it says "The backend replaces this intrinsic with the code that accesses the first argument of a call." I don't understand this sentence. A call to what? What is meant by 'accesses' - do you mean

On Dec 1, 2010, at 12:15 AM, Bill Wendling wrote: > On Dec 1, 2010, at 12:10 AM, John McCall wrote: > >> On Nov 30, 2010, at 11:04 PM, Bill Wendling wrote: >>> • A landing pad must have exactly one dispatch instruction associated with it, >>> and it must dominate that instruction. >> >> Okay, but how do we find it? >> > We can modify the

On 25 November 2010 12:01, Duncan Sands <baldrick at free.fr> wrote: > I see what you are saying now.  Unfortunately optimizations such as > inlining can result in code ending up in cleanup landing pads. This is the part that escapes me... but I haven't spent too much time thinking about inlining EH information yet. > OK :)  Essentially what happens is as follows: when

Hi all, I am interested in LLVM to develop a programing language like Java. So I am very interested VMkit.I found the website says this mailing list is where we can discuss about VMkit. But it seems there are not many posting here. Is VMkit still an active project? Which is the best project to refer to learn how to create a new language? Thank you. Shin

Hi all, I tried the step of the Getting Started page (http://vmkit.llvm.org/get_started.html) on Linux/x64 but I had no luck. I could build them. But when I tried to execute J3, it shows like follows, >> j3: JavaRuntimeJIT.cpp:367: void* j3StartJNI(uint32*, uint32**, mvm::KnownFrame*): Assertion `th->getLastSP() == th->lastKnownFrame->currentFP' failed. Does anybody know if

On Nov 24, 2010, at 5:47 AM, Renato Golin wrote: >> So the above code would look something like this: >> >> entry: >> invoke @f.run() to %bb unwind to %FooCleanup region(1) >> bb: >> invoke @b.run() to %bb2 unwind to %BarCleanup region(1) >> bb2: >> invoke @z.run() to %bb3 unwind to %BazCleanup region(1) >> ... >> BazCleanup:

I may me wrong, but I think Nathan used ints for demonstration purposes only. unwind always takes i8* argument that ideally should be a pointer to exception structure, variable %x in invoke is also typed i8*, it's not "untyped". Probably more llvm-ish syntax would be unwind i8* %x to label %catch to show the type explicitly. However throwing a pointer to a structure raises

On 25 November 2010 07:51, Duncan Sands <baldrick at free.fr> wrote: > If you got to XYZ because an instruction threw an exception before %x was > defined, then in XYZ you are using %x which was never defined.  In effect > the definition of %x in bb does not dominate the use in XYZ.  I think the > solution is to say that in XYZ you are not allowed to use any values defined >

2010/1/22 James Williams <junk at giantblob.com> > > > 2010/1/22 Duncan Sands <baldrick at free.fr> > >> Hi James, >> >> >> I get the expected output (after changing i32 @llvm.eh.selector() to i64 >>> llvm.eh.selector.i64()) >>> >> >> in top-of-tree, llvm.eh.selector.i64 has been removed (though bitcode will >>

Hi James, Looking at: %7 = invoke i8* (...)* bitcast (i32 (%struct._Unwind_Exception*)* @_Unwind_RaiseException to i8* (...)*)(i64* %6) to label %8 unwind label %.finally_pad ; <i8*> [#uses=0] I am not sure this is going to work, at least from the way I've played with the system. In my examples the _Unwind_RaiseException(...) is called from a frame (function) called via