Optimizer fails to remove instructions after abort

[SUPERCILEX]

I tried this code:

pub fn foo(_v: Vec<u8>) {
    std::process::abort()
}

Godbolt shows unwinding after the ud2 instructions which doesn't make sense:

example::foo::head1d7ed7dbf2287:
        push    r14
        push    rbx
        push    rax
        mov     r14, rdi
        call    qword ptr [rip + std::process::abort::h3e94a41c09fe797f@GOTPCREL]
        ud2
        mov     rbx, rax
        mov     rsi, qword ptr [r14]
        test    rsi, rsi
        je      .LBB0_4
        mov     rdi, qword ptr [r14 + 8]
        mov     edx, 1
        call    qword ptr [rip + __rustc[e054f922969c5460]::__rust_dealloc@GOTPCREL]
.LBB0_4:
        mov     rdi, rbx
        call    _Unwind_Resume@PLT

DW.ref.rust_eh_personality:
        .quad   rust_eh_personality

[saethlin]

I believe that code is handling the unwind edge out of the std::process::abort call. Certainly it's clear that is the case in the IR; I don't know how unwinding works on x86.

[SUPERCILEX]

But I'm confused, ud2 is an illegal instruction so nothing past that should execute. Also I thought the point of aborting was that you wouldn't return from abort. Is the idea that someone could install a SIGABRT and SIGILL handler to keep going?

[hanna-kruppe]

No, catching signals like that is not supported, and even if it was, it wouldn’t do stack unwinding so continuing the thread would probably just run into the ud2 anyway (or go completely off the rails because returning from a function that isn’t supposed to return is UB). But evidently LLVM doesn’t know that std::process::abort won’t unwind (no nounwind attribute on the LLVM IR declaration), at least not on the target you’ve tried with the compiler flags you’ve tried, so it can’t remove the landing pad.

You get similar codegen if you replace std::process::abort with a function that has return type -> ! and may panic. If it can’t panic, then in simple cases LLVM can infer that and optimize accordingly, but in the case of std::process::abort this may require link-time optimizations (but of course it isn’t guaranteed even then).

[SUPERCILEX]

Ohhhhhh, ok so the code after ud2 is actually part of the unwinding framework and the idea is that panicking knows to resume execution at that point in the function instead of going through normal ret instructions. Thanks!