search for: typeid1

...eArray case. Consider this module (based on test/Transforms/LowerTypeTests/simple.ll): @a = constant i32 1, !type !0, !type !2 @b = constant [63 x i32] zeroinitializer, !type !0, !type !1 @c = constant i32 3, !type !1, !type !2 @d = constant [2 x i32] [i32 4, i32 5], !type !3 !0 = !{i32 0, !"typeid1"} !3 = !{i32 4, !"typeid1"} !1 = !{i32 0, !"typeid2"} !2 = !{i32 0, !"typeid3"} define i1 @baz(i32* %p) { %x = call i1 @llvm.type.test(i8* %pi8, metadata !"typeid3") ret i1 %x } Here is the IR after the LowerTypeTests pass has run. I've marked...

...d on test/Transforms/ > LowerTypeTests/simple.ll): > > @a = constant i32 1, !type !0, !type !2 > @b = constant [63 x i32] zeroinitializer, !type !0, !type !1 > @c = constant i32 3, !type !1, !type !2 > @d = constant [2 x i32] [i32 4, i32 5], !type !3 > > !0 = !{i32 0, !"typeid1"} > !3 = !{i32 4, !"typeid1"} > !1 = !{i32 0, !"typeid2"} > !2 = !{i32 0, !"typeid3"} > > define i1 @baz(i32* %p) { > %x = call i1 @llvm.type.test(i8* %pi8, metadata !"typeid3") > ret i1 %x > } > > Here is the IR after t...

...gt; >>> To confirm, you mean during the compile step create a top-level entity >>> that maps GUID -> identifier? >>> >> >> I mean that you could represent this with something like: >> >> ^typeids = {^1, ^2, ^3} >> ^1 = typeid: {identifier: typeid1, ...} >> ^2 = typeid: {identifier: typeid2, ...} >> ^3 = typeid: {identifier: typeid3, ...} >> >> There's no need to store the GUIDs here because they can be computed from >> the type identifiers. The GUIDs would only be stored in the typeTests >> (etc.) fiel...

...epresent that, and I don't really have it nailed down. Here's an idea, just to brainstorm: define void @parent() { invoke ... unwind to %lpad ... lpad: %eh_vals = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__C_specific_handler to i8*) cleanup catch i8* @typeid1 catch i8* @typeid2 %label = call i8* (...)* @llvm.eh.outlined_handlers( void (i8*, i8*)* @my_cleanup, i8* @typeid1, i8* (i8*, i8*)* @my_catch1, i8* @typeid2, i8* (i8*, i8*)* @my_catch2) indirectbr i8* %label endcatch: ... } define void @my_cleanup(i8*, i8*) { ......

...med? I didn't do that in the mock-up above, but it seems like it would simplify things. Basically, I'm imagining a final pattern that looks like this: lpad: %eh_vals = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) cleanup catch i8* @typeid1 catch i8* @typeid2 ... %label = call i8* (...)* @llvm.eh.outlined_handlers( void (i8*, i8*)* @<pre-catch cleanup function>, i8* @typeid1, i8* (i8*, i8*)* @<typeid1 catch function>, i8* @typeid2, i8* (i8*, i8*)* @<typeid2 catch function>, ......

...level entity. >>> >> >> To confirm, you mean during the compile step create a top-level entity >> that maps GUID -> identifier? >> > > I mean that you could represent this with something like: > > ^typeids = {^1, ^2, ^3} > ^1 = typeid: {identifier: typeid1, ...} > ^2 = typeid: {identifier: typeid2, ...} > ^3 = typeid: {identifier: typeid3, ...} > > There's no need to store the GUIDs here because they can be computed from > the type identifiers. The GUIDs would only be stored in the typeTests > (etc.) fields in each function summ...

Thanks for the additional information. Right now I’m experimenting with a mix of code compiled with MSVC and code compiled with clang, trying to get a C++ exception thrown and caught by the MSVC-compiled code across a function in the clang-compiled code. My goal here is to isolate a small part of what needs to be done in a way that lends itself to tinkering. I think this might lead me to the

...you mean during the compile step create a top-level entity >>>> that maps GUID -> identifier? >>>> >>> >>> I mean that you could represent this with something like: >>> >>> ^typeids = {^1, ^2, ^3} >>> ^1 = typeid: {identifier: typeid1, ...} >>> ^2 = typeid: {identifier: typeid2, ...} >>> ^3 = typeid: {identifier: typeid3, ...} >>> >>> There's no need to store the GUIDs here because they can be computed >>> from the type identifiers. The GUIDs would only be stored in the typeTests...

...step create a top-level entity >>>>> that maps GUID -> identifier? >>>>> >>>> >>>> I mean that you could represent this with something like: >>>> >>>> ^typeids = {^1, ^2, ^3} >>>> ^1 = typeid: {identifier: typeid1, ...} >>>> ^2 = typeid: {identifier: typeid2, ...} >>>> ^3 = typeid: {identifier: typeid3, ...} >>>> >>>> There's no need to store the GUIDs here because they can be computed >>>> from the type identifiers. The GUIDs would only be stor...

...tity that maps GUID -> identifier? >>>>>>> >>>>>> >>>>>> I mean that you could represent this with something like: >>>>>> >>>>>> ^typeids = {^1, ^2, ^3} >>>>>> ^1 = typeid: {identifier: typeid1, ...} >>>>>> ^2 = typeid: {identifier: typeid2, ...} >>>>>> ^3 = typeid: {identifier: typeid3, ...} >>>>>> >>>>>> There's no need to store the GUIDs here because they can be computed >>>>>> from the type i...

...;>>>>> entity that maps GUID -> identifier? >>>>>> >>>>> >>>>> I mean that you could represent this with something like: >>>>> >>>>> ^typeids = {^1, ^2, ^3} >>>>> ^1 = typeid: {identifier: typeid1, ...} >>>>> ^2 = typeid: {identifier: typeid2, ...} >>>>> ^3 = typeid: {identifier: typeid3, ...} >>>>> >>>>> There's no need to store the GUIDs here because they can be computed >>>>> from the type identifiers. The GUID...

...; identifier? >>>>>>>> >>>>>>> >>>>>>> I mean that you could represent this with something like: >>>>>>> >>>>>>> ^typeids = {^1, ^2, ^3} >>>>>>> ^1 = typeid: {identifier: typeid1, ...} >>>>>>> ^2 = typeid: {identifier: typeid2, ...} >>>>>>> ^3 = typeid: {identifier: typeid3, ...} >>>>>>> >>>>>>> There's no need to store the GUIDs here because they can be computed >>>>>>...

...rainstorm: > > > > define void @parent() { > > invoke ... unwind to %lpad > > ... > > lpad: > > %eh_vals = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__C_specific_handler to i8*) > > cleanup > > catch i8* @typeid1 > > catch i8* @typeid2 > > %label = call i8* (...)* @llvm.eh.outlined_handlers( > > void (i8*, i8*)* @my_cleanup, > > i8* @typeid1, i8* (i8*, i8*)* @my_catch1, > > i8* @typeid2, i8* (i8*, i8*)* @my_catch2) > > indirectbr i8* %lab...

...s a top-level entity. >> >> To confirm, you mean during the compile step create a top-level entity that maps GUID -> identifier? >> >> I mean that you could represent this with something like: >> >> ^typeids = {^1, ^2, ^3} >> ^1 = typeid: {identifier: typeid1, ...} >> ^2 = typeid: {identifier: typeid2, ...} >> ^3 = typeid: {identifier: typeid3, ...} >> >> There's no need to store the GUIDs here because they can be computed from the type identifiers. The GUIDs would only be stored in the typeTests (etc.) fields in each functi...

...apping of type identifiers as a top-level entity. > > To confirm, you mean during the compile step create a top-level entity that maps GUID -> identifier? > > I mean that you could represent this with something like: > > ^typeids = {^1, ^2, ^3} > ^1 = typeid: {identifier: typeid1, ...} > ^2 = typeid: {identifier: typeid2, ...} > ^3 = typeid: {identifier: typeid3, ...} > > There's no need to store the GUIDs here because they can be computed from the type identifiers. The GUIDs would only be stored in the typeTests (etc.) fields in each function summary. >...

...;>>>>> entity that maps GUID -> identifier? >>>>>> >>>>> >>>>> I mean that you could represent this with something like: >>>>> >>>>> ^typeids = {^1, ^2, ^3} >>>>> ^1 = typeid: {identifier: typeid1, ...} >>>>> ^2 = typeid: {identifier: typeid2, ...} >>>>> ^3 = typeid: {identifier: typeid3, ...} >>>>> >>>>> There's no need to store the GUIDs here because they can be computed >>>>> from the type identifiers. The GUID...

...t;> >>>>>>>>> >>>>>>>>> I mean that you could represent this with something like: >>>>>>>>> >>>>>>>>> ^typeids = {^1, ^2, ^3} >>>>>>>>> ^1 = typeid: {identifier: typeid1, ...} >>>>>>>>> ^2 = typeid: {identifier: typeid2, ...} >>>>>>>>> ^3 = typeid: {identifier: typeid3, ...} >>>>>>>>> >>>>>>>>> There's no need to store the GUIDs here because they can be &...

...gt;>>>>>> >>>>>>>>>> I mean that you could represent this with something like: >>>>>>>>>> >>>>>>>>>> ^typeids = {^1, ^2, ^3} >>>>>>>>>> ^1 = typeid: {identifier: typeid1, ...} >>>>>>>>>> ^2 = typeid: {identifier: typeid2, ...} >>>>>>>>>> ^3 = typeid: {identifier: typeid3, ...} >>>>>>>>>> >>>>>>>>>> There's no need to store the GUIDs here becau...

...t;> >>>>>>>>> >>>>>>>>> I mean that you could represent this with something like: >>>>>>>>> >>>>>>>>> ^typeids = {^1, ^2, ^3} >>>>>>>>> ^1 = typeid: {identifier: typeid1, ...} >>>>>>>>> ^2 = typeid: {identifier: typeid2, ...} >>>>>>>>> ^3 = typeid: {identifier: typeid3, ...} >>>>>>>>> >>>>>>>>> There's no need to store the GUIDs here because they can be &...

...ping of type identifiers as >> a top-level entity. >> > > To confirm, you mean during the compile step create a top-level entity > that maps GUID -> identifier? > I mean that you could represent this with something like: ^typeids = {^1, ^2, ^3} ^1 = typeid: {identifier: typeid1, ...} ^2 = typeid: {identifier: typeid2, ...} ^3 = typeid: {identifier: typeid3, ...} There's no need to store the GUIDs here because they can be computed from the type identifiers. The GUIDs would only be stored in the typeTests (etc.) fields in each function summary. Peter > > Thanks...