[clang] [llvm] Fix Windows EH IP2State tables (remove +1 bias) (PR #144745)
Eli Friedman via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 8 21:48:19 PDT 2025
================
@@ -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
More information about the llvm-commits
mailing list