search for: endcatch

...pecific_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*) { ... ret void ; unwinder will keep going for cleanups } define i8* @my_catch1(i8*, i8*) { ret i8* blockaddress(@parent, %endcatch) ; merge back into normal flow at endcatch } define i8* @my_catch2(i8*, i8*) { ret i8* blockaddress(@parent, %endc...

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

...st week in an LLVMDev discussion of C++ EH support on Windows, but I thought I should float it again with a subject that would be less likely to be missed by people who don't have a direct interest in Windows support. I would like to introduce two new intrinsics, llvm.eh.begincatch and llvm.eh.endcatch, to take the place of __cxa_begin_catch and __cxa_end_catch in the IR prior to the CodeGen prepare passes. For the majority of platforms the intrinsics will be directly mapped to the existing function calls during one of the CodeGen prepare passes. For MSVC-environment Windows targets there is no...

...@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*) { > > ... > > ret void ; unwinder will keep going for cleanups > } > > > > define i8* @my_catch1(i8*, i8*) { > > ret i8* blockaddress(@parent, %endcatch) ; merge ba...

...write @llvm.experimental.stackmap @llvm.experimental.patchpoint @llvm.experimental.gc.statepoint @llvm.returnaddress @llvm.frameaddress @llvm.localescape @llvm.localrecover @llvm.stacksave @llvm.stackrestore @llvm.pcmarker @llvm.readcyclecounter @llvm.bitreverse @llvm.eh.begincatch @llvm.eh.endcatch @llvm.eh.padparam @llvm.stackprotector @llvm.stackprotectorcheck @llvm.objectsize @llvm.donothing Words with dots: @llvm.sadd.with.overflow @llvm.uadd.with.overflow @llvm.ssub.with.overflow @llvm.usub.with.overflow @llvm.smul.with.overflow @llvm.umul.with.overflow @llvm.convert.to.fp16 @llvm....

On Fri, May 15, 2015 at 5:27 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I like the way this sorts out with regard to funclet code generation. > It feels very natural for Windows EH, though obviously not as natural for > non-Windows targets and I think it is likely to block some optimizations > that are currently possible with those targets. > Right, it will

> 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

...rt enough to do #3, which could implement #1 by additional outlining. It's ugly though. =/ In practice, I don't think this situation will occur very often because the catch blocks look like this: catch_int: call void @llvm.eh.begincatch(i8* %ehptr) ... ; user code call void @llvm.eh.endcatch() ... ; rejoin normal control Anything we can hoist out of "user code" here can usually be sunk back in. If it's not trivial like a hoisted store to an unescaped internal global, then we'll have to emit something that looks like a destructor cleanup. On Thu, Feb 12, 2015 at 7:...

These are exactly the sorts of code transformations we want to allow by delaying the outlining until later. By keeping such code inlined in the parent function until after optimization, we enable a lot of core optimizations like SROA. For example, we should be able to completely eliminate wrappers like unique_ptr that would otherwise stay around due to the pointer escaped to the destructor call

...o: Reid Kleckner; Joseph Tremoulet Cc: Bataev, Alexey; Reid Kleckner (reid at kleckner.net); LLVM Developers Mailing List Subject: RE: [LLVMdev] RFC: Native Windows C++ exception handling It’s an interesting problem though. If an instruction is in the landing pad block but not inside a begincatch/endcatch pair it will be interpreted as cleanup code. I think that is OK, but it’s something we’ll need to be aware of. For reference, Joseph’s first scenario will look like this: ; Function Attrs: uwtable define i32 @_Z3fooii(i32 %a, i32 %b) #0 { entry: <…snip…> store i32 %a, i32* %a.addr, ali...