search for: lpad1

...%entry %0 = load i32** %i.addr, align 8 %1 = load i32* %0, align 4 %cmp = icmp eq i32 %1, 1 br i1 %cmp, label %if.then, label %if.else if.then: ; preds = %invoke.cont invoke void @_Z12do_thing_onev() to label %invoke.cont2 unwind label %lpad1 invoke.cont2: ; preds = %if.then br label %if.end ; From 'entry' invoke of Middle constructor ; outer needs post-catch cleanup lpad: ; preds = %if.end, %entry %2 = landingpad { i8*, i32 } personality i8*...

...with whoever created such an atrocity, but I didn’t feel like we could just assume it can’t happen. If we follow the branch to “normal.cont2” it could conceivably take us through the entire CFG for the function. Obviously we want to avoid that. 2) A block shared between unconnected landing pads lpad1: landingpad … cleanup catch <some type> … … br label %shared.block lpad2: landingpad … cleanup catch <some other type> … … br label %shared.block shared.block: %dst = phi i1 [1, %lpad1], [0, %lpad2] ; do something that happens in both cleanup handlers...

Hi Reid, Is this design supposed to be able to cope with asynchronous exceptions? I am having trouble imagining how this would work without adding the ability to associate landing pads with scopes in LLVM IR. Vadim On Tue, Nov 25, 2014 at 5:27 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Nov 25, 2014 at 3:09 PM, Kaylor, Andrew <andrew.kaylor at intel.com> > wrote:

Hello, Why does LLVM use __gcc_personality_v0 instead of __gxx_personality_v0 function when it lowers llvm.gcroot intrinsic? For my try-catch codegen I use last one (so does clang) and it conflicts with __gcc_personality_v0 produced by LLVM? I know how to solve it with my own GC plug-in, just wondering. And what's the difference between these two functions anyway? Thanks,

...block, but it introduces a lot of implicit control flow, > which we don't like: > http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt > > You would do this: > %p = call i8* malloc(i32 4) > %xp = bitcast i8* %p to i32* > ... > > mybb: unwind to label %lpad1 > %x = load i32* %xp ; edge to lpad1 here > store i32 0, i32* %xp ; edge to lpad1 here > call void @f() ; edge to lpad1 here > br label %mybb2 ; cannot remove branch due to differing lpads > > mybb2: unwind to label %lpad2 > ... > > lpad: > %xx = load i32*...

...etNodeIDERPv(%"class.llvm::FoldingSetImpl"* getelementptr inbounds (%"class.llvm::FoldingSet"* @_ZZN4llvm8BitsInit3getENS_8ArrayRefIPNS_4InitEEEE7ThePool, i64 0, i32 0), %"class.llvm::FoldingSetNodeID.3597"* %ID, i8** %IP) to label %call.i.noexc unwind label %lpad1.nonloopexit Call parameter type does not match function signature! %"class.llvm::FoldingSetImpl"* getelementptr inbounds (%"class.llvm::FoldingSet"* @_ZZN4llvm8BitsInit3getENS_8ArrayRefIPNS_4InitEEEE7ThePool, i64 0, i32 0) %"type 0x100e180c0"* invoke void @_ZN4llvm14...

(Moving this discussion on list as this could be of general interest.) My current work-in-progress implementation is attempting to map out the blocks used by a landing pad before it starts outlining. It creates a table of catch and cleanup handlers with the block at which each one starts. During outlining I intend to have another mechanism to check to see if we’ve already outlined the handler

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

...n 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 think it will help if I explain the handling of that case a bit more in terms of the .xdata tables that will eventually need to be generated, and maybe then we can converge on a reasonab...

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

...%capture_block, i32 0, i32 1 invoke void @_ZN5OuterC1Ev(%struct.Outer* %outer) to label %invoke.cont unwind label %lpad invoke.cont: ; 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)...

...4 Segmentation fault Removing all calls to mytrace makes behavior correct. Why I can't insert trace instructions? What is the state that is saved between commands that causes such crashes? Also only leaving one 'mytrace ' instruction before or after llvm.eh.exception near the label lpad1 already causes the crash. I think something is wrong with llvm.eh.exception and/or llvm.eh.selector. Do they pass each other values in registers or something like this? Yuri -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: c.C URL: <http:...