================
@@ -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

Reply via email to