Allow linking a prebuilt optimized compiler-rt builtins library

[pmur]

Extend the .optimized-compiler-builtins bootstrap option to accept a path to a prebuilt compiler-rt builtins library, and update compiler-builtins to enable optimized builtins without building compiler-rt builtins.

[rustbot]

r? @Kobzol

rustbot has assigned @Kobzol.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

This PR modifies bootstrap.example.toml.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

compiler-builtins is developed in its own repository. If possible, consider making this change to rust-lang/compiler-builtins instead.

cc @tgross35

[Kobzol]

I don't really know much about the optimized compiler-rt builtins. Maybe @tgross35 might know more?

[Mark-Simulacrum]

Can you say more about how much time this saves? Historically it's been my impression locally that building is basically free, this flag is more about whether it's possible to build (e.g., needs to be off if you're ad-hoc cross compiling). Though maybe I'm remembering wrong?

[pmur]

Can you say more about how much time this saves? Historically it's been my impression locally that building is basically free, this flag is more about whether it's possible to build (e.g., needs to be off if you're ad-hoc cross compiling). Though maybe I'm remembering wrong?

The goal is to enable optimized compiler-builtins in fedora packaging. There, rust is built using the distro provided llvm and resulting libraries. Some runtime features are absent if optimized compiler-builtins are not used. Notably, outlined aarch64 LSE atomic operations are not available without this support.

[cuviper]

Right, it's less about time and more about wanting to use our existing system LLVM packages.

[pmur]

Ping @tgross35. The intent here is to enable optimized-builtins in Fedora using the system's compiler-rt.builtins library.

[tgross35]

The changes to compiler-builtins lgtm with a possible rename of the var, assuming you have verified this works locally. Somebody more familiar with bootstrap (@Kobzol?) will need to review the changes there.

[pmur]

The changes to compiler-builtins lgtm with a possible rename of the var, assuming you have verified this works locally. Somebody more familiar with bootstrap (@Kobzol?) will need to review the changes there.

I did test builds with the fedora targets (excepting s390x, it lacks a libcompiler-rt.builtins library in rawhide right now). Likewise, I verified the LSE support linked in for aarch64 does work.

Is it a realistic case to consider something trying to link libgcc.a or libcompiler-rt.builtins.a when std already includes a copy of libcompiler-rt.builtins? That case I haven't tested.

[tgross35]

Does println!("cargo::rustc-link-arg={}", rt_builtins_ext.to_str().unwrap()) work to replace these by chance? I think passing the exact path to the linker should avoid needing to set both -l and -L.

[pmur]

That seems like it should work, but trying locally (x86-64-unknown-linux-gnu) didn't work as expected. The builtins library wasn't copied into the .rlib as is the case with the above or letting rust built them.

[tgross35]

Is it a realistic case to consider something trying to link libgcc.a or libcompiler-rt.builtins.a when std already includes a copy of libcompiler-rt.builtins? That case I haven't tested.

I think this can happen in niche build setups, but no special handling should be needed; all three libraries make their builtin symbols weak, so conflicts aren't a problem.

[bors]

☔ The latest upstream changes (presumably #144773) made this pull request unmergeable. Please resolve the merge conflicts.

[pmur]

Is it a realistic case to consider something trying to link libgcc.a or libcompiler-rt.builtins.a when std already includes a copy of libcompiler-rt.builtins? That case I haven't tested.

I think this can happen in niche build setups, but no special handling should be needed; all three libraries make their builtin symbols weak, so conflicts aren't a problem.

The rust versions are weak, I am not sure the library built by optimized-compiler-builtins or the system provided libclang_rt.builtins.a exposes weak builtin functions. When I tried explicitly linking a second time on aarch64, it raised errors.