================ @@ -9,7 +9,6 @@ define i32 @foobar() gc "statepoint-example" personality ptr @__gxx_personality_ ; CHECK-NEXT: .seh_endprologue ; CHECK-NEXT: callq bar ; CHECK-NEXT: .Ltmp0: -; CHECK-NEXT: nop ---------------- efriedma-quic wrote:
So the conclusion here is this particular case doesn't need the nop? Fine, I guess. I suspect there's an underlying issue with the algorithm, though. Consider the following C++ function: ```C++ [[noreturn]] void g1(); void g2(); struct A { ~A(); }; void f(bool b) { if (b == false) g1(); A a; g2(); } ``` Compile with: ``` clang -O2 --target=x86_64-windows-msvc -mllvm -opt-bisect-limit=127 ``` Produces: ``` pushq %rbp .seh_pushreg %rbp subq $48, %rsp .seh_stackalloc 48 leaq 48(%rsp), %rbp .seh_setframe %rbp, 48 .seh_endprologue movq $-2, -8(%rbp) testb %cl, %cl jne .LBB0_2 jmp .LBB0_1 .LBB0_1: # %if.then callq "?g1@@YAXXZ" .LBB0_2: # %if.end .Ltmp0: # EH_LABEL callq "?g2@@YAXXZ" nop [...] ``` You end up in the wrong region if g1 unwinds, I think. (Not sure off the top of my head how to reproduce this without opt-bisect-limit, but I'm sure there's some way.) https://github.com/llvm/llvm-project/pull/144745 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits