search for: begincatch

..., I brought this up last 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 Window...

...ntly working on a problem where the WinEHPrepare outlining code stumbles and asserts while cloning code that references extracted landing pad values via PHI nodes that are in intermediate blocks that aren't being cloned. The test I'm looking at fails with an assertion claiming that llvm.eh.begincatch was called twice inside a handler. I have an idea for how to address this (giving the cloning director a chance to replace operands before an instruction is remapped). I'll put something up for review as soon as I have it working. In the mean time I wanted to make sure you weren't workin...

...sider your example where a + b gets hoisted before the catch dispatch. Adds have no side effects, so we can freely sink them back down into the catch handler once we start outlining. Things that are hard to move, like loads and stores to unknown memory locations, cannot be hoisted over the llvm.eh.begincatch() call in the first place. It should act as a memory barrier. I have the same question about the post-outlining IR. To change the example to one where the bait won't get outlined, suppose you had int foo(int a, int b) { try { try { maybe_throw(); return 0; } catch (int)...

...llvm.gcread @llvm.gcwrite @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.conv...

...add i32 %s2, 1 ret i32 %s3 } But even if we aren't smart 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...

...5 2:06 PM To: 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....

...’m currently working on a problem where the WinEHPrepare outlining code stumbles and asserts while cloning code that references extracted landing pad values via PHI nodes that are in intermediate blocks that aren’t being cloned. The test I’m looking at fails with an assertion claiming that llvm.eh.begincatch was called twice inside a handler. I have an idea for how to address this (giving the cloning director a chance to replace operands before an instruction is remapped). I’ll put something up for review as soon as I have it working. In the mean time I wanted to make sure you weren’t working on the...

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