search for: lpad3

I am working on adding support for C++ exception handling when compiling for a native Windows target (that is a target with "MSVC" specified as the environment). Because of differences between how the native Windows runtime handles exceptions and the Itanium-based model used by current LLVM exception handling code, I believe this will require some extensions to the LLVM IR, though

...ere. (Maybe that’s an argument for using a different construct.) There’s also a good chance that I’m being inconsistent in how I chose to represent catch clauses versus cleanup clauses. In the case you refer to, if an exception thrown by do_inner_thing() is caught by the int exception handler at lpad3, then we only want ~Iinner() to be called. If it is caught instead by the float handler, that will result in a different state transition and the call to ~Outer() will be made by the lpad1 cleanup. Having actually written that explanation now, I see the confusion inherent in my original proposal....

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 = %entry invoke void @_ZN5InnerC1Ev(%struct.Inner* %inner) to label %invoke.cont2 unwind label %lpad1 invoke.cont2: ; preds = %invoke.cont invoke void @_Z14do_inner_thingv() to label %invoke.cont4 unwind label %lpad3 invoke.cont4: ; preds = %invoke.cont2 invoke void @_ZN5InnerD1Ev(%struct.Inner* %inner) to label %try.cont unwind label %lpad1 try.cont: ; preds = %invoke.cont4, %invoke.cont8 invoke void @_ZN5OuterD1Ev(%str...