smeenai added a comment. @rnk remember how I was asking you about inlining into catchpads on IRC a few days back? It was in relation to this change.
If I have a file `finally1.m`: void f(void); void g() { @try { f(); } @finally { f(); } } and compile it with: clang -cc1 -triple i686-windows-msvc -fobjc-runtime=ios-6.0 -fexceptions -fobjc-exceptions -Os -emit-llvm -o - finally1.m the @finally calls out to the captured statement instead of inlining it: finally.catchall: ; preds = %catch.dispatch %1 = catchpad within %0 [i8* null, i32 64, i8* null] call fastcc void @__captured_stmt() [ "funclet"(token %1) ] call void @_CxxThrowException(i8* null, %eh.ThrowInfo* null) #3 [ "funclet"(token %1) ] unreachable If I add an outer try-catch scope, as in `finally2.m`: void f(void); void g() { @try { @try { f(); } @finally { f(); } } @catch (...) { } } and run the same compilation command: clang -cc1 -triple i686-windows-msvc -fobjc-runtime=ios-6.0 -fexceptions -fobjc-exceptions -Os -emit-llvm -o - finally2.m the @finally inlines the captured statement: finally.catchall: ; preds = %catch.dispatch %2 = catchpad within %0 [i8* null, i32 64, i8* null] invoke void @f() #2 [ "funclet"(token %2) ] to label %invoke.cont1 unwind label %catch.dispatch4 invoke.cont1: ; preds = %finally.catchall invoke void @_CxxThrowException(i8* null, %eh.ThrowInfo* null) #3 [ "funclet"(token %2) ] to label %unreachable unwind label %catch.dispatch4 Any idea why we would see inlining in one case and not the other? i686 vs. x86-64 doesn't make any difference, and neither does -Os vs. -O1 vs. -O2. Repository: rC Clang https://reviews.llvm.org/D47988 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits