LLVM Bitcode Linker: A self contained linker for nvptx and other targets by kjetilkjeka · Pull Request #117458 · rust-lang/rust (original) (raw)

Can we require fat LTO for nvptx? When rustc does fat LTO it already combines all crates into a single object file.

It would certainly be possible, rust is capable of calling the right functions in llvm to make it work. But it doesn't work "out of the box" and I'm not certain it's the correct thing to do long term eiteher.

If we decided to use only lto="fat" we would disallow lto="thin" which helps a lot with compile times. One could argue that the general ptx program is small enough for this to be acceptable, but it doesn't feel right to leave such an optimization out without an excellent reason. Perhaps a bigger problem is that linker-plugin-lto would not work which would make cross-language lto more difficult.

When it comes to compiler change we would still need to add llc as a linker known to the compiler. This is required to compile from llvm-bitcode to native. The linker would be an unconventional one as it would not actually be able to link anything and only accept a single bitcode file as input.

When I tested it just now it seems like libcompiler_builtins still produces an .rlib which is linked by the linker even when lto = "fat". I'm not sure if this is a bug or expected behavior, but it must be resolved before we may assume that the linker is only given a single bitcode file. (Note: -Zbuild-std=core is required due to not distributing this library and LTO towards libcore is required to work around some bugs right now and desired at the long term since calling functions on ptx is tremendously expensive.)

As an addition, there might be future benefits an approach as this embedded-linker can have to other targets than ptx as well. Maybe it can be used to bring thin lto to embedded targets where the native linker doesn't support it. It can also provide compilation without requiring to install an external target specific linker.

Is this an approach we would like to explore further even with the known deficiencies listed above? Is the main advantage that we avoid yet another tool that needs to be maintained? Or that we get more control using libLLVM compared to calling the llvm tools?