search for: _ztipkc

> %exn.val = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0 > catch i8** @_ZTIi, i8** @_ZTId > filter i8** @_ZTIPKc > br label %lpad.split What is the semantics of filter? Is it undefined reference if an exception not matching ZTIi, ZTId or ZTIPKc passes by? Cheers, Rafael

...each invoke. Right now you have invoke void @_Z3foov() to label %invcont unwind label %catch.handlers catch.handlers: landingpad dispatch resume to label %... catches [ %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %ch.str ] catchall [i8* null, label % ch.ca] Why not combine this into: invoke void @_Z3foov() to label %invcont unwind resume to label %... catches [ %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int %struct.__pointer_type_info_pseudo* @_ZTIP...

...gt; invoke void @_Z3foov() > to label %invcont unwind label %catch.handlers > > catch.handlers: landingpad > dispatch resume to label %... > catches [ > %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int > %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %ch.str > ] > catchall [i8* null, label % ch.ca] > > Why not combine this into: > > invoke void @_Z3foov() > to label %invcont unwind resume to label %... > catches [ > %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int >...

...ers>] Here's an example where there is no cleanup and there are two handlers: invoke void @_Z3foov() to label %invcont unwind label %catch.handlers personality @__gxx_personality_v0 catches %struct.__fundamental_type_info_pseudo* @_ZTIi, %struct.__pointer_type_info_pseudo* @_ZTIPKc Note that unlike in Bill's proposal there isn't a label for each catch object, just one global label (the existing unwind label). The semantics of the invoke instruction are slightly modified: if an exception unwinds and it doesn't match anything in the list of catches and filters, an...

...esented in LLVM IR is target specific. // Examples: ;; A landing pad which can catch an integer or double and which can throw only ;; a const char *. %res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0 catch i8** @_ZTIi, i8** @_ZTId filter i8** @_ZTIPKc ;; A landing pad that is a cleanup. %res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0 cleanup ;; A landing pad which indicates that the personality function should call the ;; terminate function. %res = landingpad { i8*, i32 } personality i32 (...)*...

...ic. > > // Examples: > > ;; A landing pad which can catch an integer or double and which can throw only > ;; a const char *. > %res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0 > catch i8** @_ZTIi, i8** @_ZTId > filter i8** @_ZTIPKc > > ;; A landing pad that is a cleanup. > %res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0 > cleanup > > ;; A landing pad which indicates that the personality function should call the > ;; terminate function. > %res = landingpad {...

...example where there is no cleanup and there are two handlers: > > invoke void @_Z3foov() > to label %invcont unwind label %catch.handlers personality > @__gxx_personality_v0 catches %struct.__fundamental_type_info_pseudo* @_ZTIi, > %struct.__pointer_type_info_pseudo* @_ZTIPKc > > Note that unlike in Bill's proposal there isn't a label for each catch > object, just one global label (the existing unwind label). > > The semantics of the invoke instruction are slightly modified: if an exception > unwinds and it doesn't match anything in the l...

Hi Bill, >> Why not combine this into: >> >> invoke void @_Z3foov() >> to label %invcont unwind resume to label %... >> catches [ >> %struct.__fundamental_type_info_pseudo* @_ZTIi, label %ch.int >> %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %ch.str >> ] >> catchall [i8* null, label % ch.ca <http://ch.ca>] >> >> ? That would get rid of the "landingpad" basic block attribute, and rules about >> what can branch to landing pads, that these cannot be split etc. Your rules >> mean t...

...Os @.str = private constant [16 x i8] c"caught int: %d\0A\00", align 1 @.str1 = private constant [19 x i8] c"caught string: %s\0A\00", align 1 @.str2 = private constant [9 x i8] c"catchall\00", align 1 @_ZTIi = external constant %struct.__fundamental_type_info_pseudo @_ZTIPKc = external constant %struct.__pointer_type_info_pseudo define void @_Z3barv() optsize ssp { entry: %a = alloca %struct.A, align 8 %b = alloca %struct.B, align 8 %c = alloca %struct.C, align 8 invoke void @_Z3foov() to label %invcont unwind label %catch.handlers invcont: invoke...

...* The "filters" clause lists the types of exceptions which may be thrown by the region. Example: ;; With catch-all block dispatch region(37) resume to label %Resume [ %struct.__fundamental_type_info_pseudo* @_ZTIi, label %bb1.lpad %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %bb2.lpad ] catchall [i8* null, label %catchall.lpad] filters [i8* bitcast (%struct.__pointer_type_info_pseudo* @_ZTIPKc to i8*), i8* bitcast (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*] ;; No catch-all block dispatch region(927) resume to label %Resu...

...dead. But it isn't! Got an example where it is? > Example, if you have this: > > invoke void @foo() > to label %invcont unwind label %lpad > personality @__gxx_personality_v0 > catches %struct.__fundamental_type_info_pseudo* @_ZTIi, > %struct.__pointer_type_info_pseudo* @_ZTIPKc > > lpad: > call void @bar(%A* %a) ; a cleanup > br label %ppad > > ppad: > %eh_ptr = call i8* llvm.eh.exception() > %eh_sel = call i32 llvm.eh.selector() > ; code to clean up. > > The call to @bar can insert an arbitrarily complex amount of code, including > inv...

>  dispatch region(927) resume to label %Resume [ >      %struct.__fundamental_type_info_pseudo* @_ZTIi, label %bb1.lpad >      %struct.__pointer_type_info_pseudo* @_ZTIPKc, label %bb2.lpad >    ] How do you handle two language types that map to the same LLVM type? Some languages need fancier catches. For example, being able to catch any object of class foo or a class that derives from foo. This is to be implemented by having a landing pad for foo that does the n...

> How do you handle two language types that map to the same LLVM type? Duncan just explained to me on IRC that it is just the globals that are used, not the types. LGTM :-) Cheers, Rafael

2010/11/25 Rafael Espíndola <rafael.espindola at gmail.com>: >> How do you handle two language types that map to the same LLVM type? > > Duncan just explained to me on IRC that it is just the globals that > are used, not the types. LGTM :-) Can someone elaborate on the mailing list? I still don't really understand this aspect. Reid

...xample where it is? > >> Example, if you have this: >> >> invoke void @foo() >> to label %invcont unwind label %lpad >> personality @__gxx_personality_v0 >> catches %struct.__fundamental_type_info_pseudo* @_ZTIi, >> %struct.__pointer_type_info_pseudo* @_ZTIPKc >> >> lpad: >> call void @bar(%A* %a) ; a cleanup >> br label %ppad >> >> ppad: >> %eh_ptr = call i8* llvm.eh.exception() >> %eh_sel = call i32 llvm.eh.selector() >> ; code to clean up. >> >> The call to @bar can insert an arbitra...

...t; lpad: > %eh_ptr = tail call i8* @llvm.eh.exception() > %eh_select27 = tail call i32 (i8*, i8*, ...)* > @llvm.eh.selector(i8* %eh_ptr, > i8* @__gxx_personality_v0, > i8* @_ZTIi, > i8* @_ZTIPKc, > i8* null) > %eh_typeid = tail call i32 @llvm.eh.typeid.for( @_ZTIi ) > %6 = icmp eq i32 %eh_select27, %eh_typeid > br i1 %6, label %bb1, label %ppad > > ppad: > %eh_typeid55 = tail call i32 @llvm.eh.typeid.for( @_ZTIPKc ) >...

...%lpad return: ret void lpad: %eh_ptr = tail call i8* @llvm.eh.exception() %eh_select27 = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector(i8* %eh_ptr, i8* @__gxx_personality_v0, i8* @_ZTIi, i8* @_ZTIPKc, i8* null) %eh_typeid = tail call i32 @llvm.eh.typeid.for( @_ZTIi ) %6 = icmp eq i32 %eh_select27, %eh_typeid br i1 %6, label %bb1, label %ppad ppad: %eh_typeid55 = tail call i32 @llvm.eh.typeid.for( @_ZTIPKc ) %7 = icmp eq i32 %eh_select27, %eh...

...ipermail/llvm-dev/attachments/20140331/913072b5/attachment-0002.patch> -------------- next part -------------- ; RUN: llvm-as < %s | llvm-dis > %t1.ll ; RUN: llvm-as %t1.ll -o - | llvm-dis > %t2.ll ; RUN: diff %t1.ll %t2.ll @_ZTIc = external constant i8* @_ZTId = external constant i8* @_ZTIPKc = external constant i8* define i8 @_Z3barv(i8* %ptr) uwtable optsize ssp { entry: %v = iload i8* %ptr to label %try.cont unwind label %lpad try.cont: ; preds = %entry, %invoke.cont4 ret i8 %v lpad:...

...to replace all the catch info with a single global constant (which would be in the llvm.metadata section) that contains the info. So an invoke would look like this (I left bitcasts off the global): @catch32 = private constant { i8*, i1, { i8*, i8* }} = { @__gxx_personality_v0, false, { @_ZTIi, @_ZTIPKc } } ; would be in metadata section, I forget the syntax ... invoke void @_Z3foov() to label %invcont unwind label on @catch32 Or something like that. Anyway, personalities, type infos etc would no longer be hard-wired into the IR. > >> Do you have an idea for how to ke...