search for: setehstate

...handle_float(); } keep_going(); } ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Original ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Function Attrs: uwtable define void @_Z4testv() #0 { entry: %outer = alloca %class.Outer, align 1 %inner = alloca %class.Inner, align 1 call void @llvm.eh.setehstate(i32 0) invoke void @_ZN5OuterC1Ev(%class.Outer* %outer) to label %invoke.cont unwind label %lpad invoke.cont: call void @llvm.eh.setehstate(i32 1) call void @llvm.eh.setehstate(i32 2) invoke void @_ZN5InnerC1Ev(%class.Inner* %inner) to label %invoke.cont1 unwind label %...

Hi Reid, Thanks for the input. You wrote: > The @_Z4testv.unwind.1 helper just calls ~Inner(), but not ~Outer. That’s actually intentional. The thing to keep in mind is that all of the landing pads are going to be effectively removed by the time the final object image is generated. They are just there to facilitate the table generation, and in the __CxxFrameHandler3 case they don’t mean

...d to form the ip2state table. Unfortunately, bracketed intrinsics aren't quite enough to recover the natural scoping of the source program, which is something we've seen with @llvm.lifetime.start / end. What should the backend do if it sees control flow like this? bb0: call void @llvm.eh.setehstate(i32 0) br label %bb3 bb1: call void @llvm.eh.setehstate(i32 2) br label %bb3 bb3: invoke void @do_something() ; Which EH state are we in? We could establish IR rules that such join points need to reset the EH state, but then we have to go and teach optimizers about it. It's basically a...