rnk added a comment. Thanks!
In D124762#3485478 <https://reviews.llvm.org/D124762#3485478>, @sgraenitz wrote: > I guess testing must be split in two: > > - Clang wants to make sure the "funclet" bundle operand gets emitted for ObjC > ARC runtime calls on Windows. Maybe that fits into > clang/test/CodeGenObjC/gnu-exceptions.m > <https://github.com/llvm/llvm-project/blob/main/clang/test/CodeGenObjC/gnu-exceptions.m>? That seems like a good template for a new test. I think it probably deserves its own file. I imagine it will grow to be a more extensive test suite covering the interaction between GNUstep Objective C exceptions and WinEH. > - LLVM wants to check that WinEHPrepare handles these runtime calls > correctly. For that maybe I can use llvm/test/CodeGen/X86/win-funclet-cfi.ll > <https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/X86/win-funclet-cfi.ll> > as a template and adjust it for the ObjC ARC case? You could go that route, but I would probably start with simplified ObjC++ code, and iteratively modify that until you get the IR that has the funclets that you want to see. This is a decent starting template: void maythrow(); void arcOpsInFunclet() { try { maythrow(); } catch (...) { // Do things that generate ARC intrinsics, probably set up an `id` variable. } } Maybe you could make the test plain ObjC, but I don't know it very well. Lastly, I think the inliner needs to be taught that these intrinsics need to carry operand bundles, otherwise this problem will arise after optimization. The inliner has the same logic here: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Utils/InlineFunction.cpp#L2311 The test case for this should be: struct Foo { inline __attribute__((always_inline)) ~Foo() { /* ARC ops to inline */ } }; void maythrow(); void bar() { Foo o; maythrow(); } ================ Comment at: llvm/lib/CodeGen/WinEHPrepare.cpp:966 - if (FuncletBundleOperand == FuncletPad) + if (!FuncletPad || FuncletBundleOperand == FuncletPad) continue; ---------------- Is this change necessary? It seems like it shouldn't be after the clang and preisel pass changes. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D124762/new/ https://reviews.llvm.org/D124762 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits