Is the build flag `linker-plugin-lto` still needed?

help
1

I've been doing some experiments with LTO across the FFI and it seems like linker-plugin-lto option is not needed in certain conditions (maybe all conditions).

I have a sys crate and a separate benchmark crate that uses the sys crate. I build both with the build flags:

[target.x86_64-unknown-linux-gnu]
rustflags = [
   "-Ctarget-cpu=native",
   "-Clink-arg=-fuse-ld=lld",
   "-Clinker=clang-11",
   "-Clink-arg=-flto",
   "-Cprefer-dynamic=no",
]

I also have the following enabled in my bench crate's Cargo.toml:

[profile.bench]
opt-level = 3
codegen-units = 1
lto = true

This appears to be enough to get LTO across the FFI. I noticed LLD says it will automatically enable LTO by default

Anyone else knowledgeable in this area and have some insight into whether or not this checks out?

I'm on nightly 1.52

2

The linker-plugin-lto option is not necessary when the linking is done by rust (and lto is enabled). It is however necessary when the linking is done by something else. The most prominent example of this is Firefox: it builds rust code as a staticlib and links that with other C/C++ code.

3

Thanks for the reply. My sys crate is using cc (clang) to compile some C source code using a build.rs file

fn main() {
    cc::Build::new()
        .file("extern/picohttpparser/picohttpparser.c")
        .opt_level_str(&"fast")
        .flag("-funroll-loops")
        .flag("-msse4")
        .flag("-flto=thin")
        .flag("-march=native")
        .compile("libpicohttpparser.a");
}

My benchmark crate uses this crate to run benches. It is about 5% faster when not including linker-plugin-lto in my rustflags which is what led me to believe it is not necessary.

Any ideas on why this would be the case?

4

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.