Missed-optimization: extern "C" fn type calls are not nounwind

[gnzlbg]

See https://rust.godbolt.org/z/9UvEyu

#![feature(unwind_attributes)]

extern "C" { 
    #[unwind(allow)] fn foo(); 
    // fn bar();
    static bar: extern "C" fn(); 
    static mut BAR: i32;
}

struct Foo;
impl Drop for Foo {
    fn drop(&mut self) {
        unsafe { BAR = 42; }
    }
}

pub unsafe fn unwind() { 
    let x = Foo;
    foo(); 
    std::mem::forget(x);
}
pub unsafe fn nounwind() { 
    let x = Foo;
    bar(); 
    std::mem::forget(x);
}

When the function extern "C" { fn bar(); } is called, the nounwind function is compiled to:

example::nounwind:
        jmpq    *bar@GOTPCREL(%rip)

However, when the function type static bar: extern "C" fn(); is called, this sub-optimal machine code is emitted:

example::nounwind:
        pushq   %rbx
        movq    bar@GOTPCREL(%rip), %rax
        callq   *(%rax)
        popq    %rbx
        retq
        movq    %rax, %rbx
        callq   core::ptr::real_drop_in_place
        movq    %rbx, %rdi
        callq   _Unwind_Resume@PLT
        ud2

This means that we can't call the large majority of C FFI functions, which cannot unwind, and all of the C++ noexcept functions, which cannot unwind either, from Rust function pointers efficiently.

[RalfJung]

I don't think this is a bug. At least if we accept rust-lang/rfcs#2753, until we can track the unwinding ABI in fn ptr types, we cannot and should not assume that functions can't unwind based only on their call ABI.

Before changing our codegen for fn ptrs, IMO we should accept an RFC that basically says the opposite of rust-lang/rfcs#2753.

[nagisa]

FWIW LLVM has no way of tracking "nounwind" for function pointers and since bar could be anything, LLVM cannot assume the pointer is nounwind.

[gnzlbg]

@nagisa we can apply attributes to calls through function pointers, e.g., see how clang does it: https://rust.godbolt.org/z/YMv6NJ

@RalfJung That discussion belongs to the RFC PR.

[nagisa]

@nagisa we can apply attributes to calls through function pointers, e.g., see how clang does it: https://rust.godbolt.org/z/YMv6NJ

The code generated by clang applies no attributes to its arguments in LLVM-IR, All that happens is clang carefully selecting whether to generate call or invoke during lowering to LLVM, which is different. Though it is true that Rust could do the same, but this then touches heavily upon how certain RFCs will go.

[Centril]

certain RFCs will go.

@nagisa specifically which ones?

[gnzlbg]

@nagisa See https://godbolt.org/z/7nnS_v, we currently optimize

extern "C" { fn foo(); } 
static FOO: unsafe extern "C" fn() = foo;
pub unsafe fn bar() { FOO() } 

to essentially this

extern "C" { fn foo(); } 
pub unsafe fn bar() { foo() } // bar is nounwind because foo is nounwind

This optimization is sound if the extern "C" ABI of the function pointer is the same as the extern "C" ABI of the function declaration. Since currently they don't unwind this allows us to remove the landing pads in bar and and make bar nounwind (the static is removed because it is private).

Declaring a function with the wrong ABI cannot probably be made UB since it is something that safe Rust code can do, calling an incorrect function declaration is definitely UB. Here, we never call the declaration, only the function pointer. If it were ok for the function pointer to unwind, then AFAICT at least two of the optimizations above (removing the landing pads and making bar nounwind) are unsound and we'd need to stop doing them.

So AFAICT we are already optimizing Rust code under the assumption that the extern "C" ABI of function pointers matches that of function declarations and definitions. We are just not as clever as clang when it comes to choosing call over invoke when we know that an ABI does not unwind.

[comex]

Even if we had a separate extern "C+unwind" or similar, we’d probably translate calls to function pointers of that ABI to the same IR that we currently generate for extern "C". Thus, if you declared a function as extern "C", created a pointer to it, casted that to an extern "C+unwind" function pointer, and called the new pointer, you’d run into the same optimization.

As such, either:

• The optimization is incorrect; or
• If a function declaration has the wrong ABI, it’s UB not only to call the function directly, but also to call a function pointer derived from that declaration, even if the pointer is casted to the correct type first.

Either way, it seems like an orthogonal issue to whether or not extern "C" function pointers should be implicitly unwind-capable.

[RalfJung]

So AFAICT we are already optimizing Rust code under the assumption that the extern "C" ABI of function pointers matches that of function declarations and definitions.

We are optimizing based on the assumption that calling a function through a function pointer behaves the same as if calling the function directly.
If we can figure out the function the pointer points to, and if that function is nounwind, that lets us assume that the fn ptr call is also nounwind. And that's what we see happening here.

[RalfJung]

That discussion belongs to the RFC PR.

Well, right now we are (in our handling of fn ptrs) future compatible with extern "C" functions existing that can unwind. Given those RFCs, now is a bad time to remove that bit of future compatibility.

specifically which ones?

rust-lang/rfcs#2753, I imagine.