search for: catch_float

> We'd have to hoist a + b to somewhere that dominates L1 and L2. I think the only BB in your program that dominates is the entry block I don't follow. What path do you see from entry to either L1 or L2 that doesn't pass through the indirectbr? In order to reach either L1 or L2, the call to maybe_throw() must raise an exception (else we'd return 0 from foo), the exception must

...entry: invoke void @maybe_throw() to label %ret unwind label %lpad ret: ret i32 0 ; The return case lpad: %ehvals = landingpad { i8*, i32 } personality ... catch ... ; typeinfo for int catch ... ; typeinfo for float %sum = add i32 %a, %b ; hoisted out from catch_int and catch_float via CSE or something ... ; dispatch on the selector, effectively doing a switch catch_int: ret i32 %sum catch_float: %s1 = add i32 %sum, 1 ret i32 %s1 ... ; resume } We have a couple options during EH preparation: 1. Outline the add into a cleanup, store the result into the frameallocat...

I was thinking about this last night, and I came up with a third alternative which I think looks very promising. It’s basically a re-working of the previous alternative to use the landingpad concept rather than arbitrary fake logic, but it uses a single landing pad for the entire function that mimics the logic of the personality function to dispatch unwinding calls and catch handlers. I believe

...; preds = %try.cont, %entry %0 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) catch i8* bitcast (i8** @_ZTIf to i8*) %recover = call i8* (...)* @llvm.eh.actions( i32 1, i8* bitcast (i8** @_ZTIf to i8*), void (i8*, i8*)* @catch_float) indirectbr i8* %recover, [label %try.cont], [label %try.cont19] lpad1: ; preds = %invoke.cont4, %invoke.cont %3 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) cleanup catch i8* bitcast...