clang and link-time-optimization

[no-longer-on-githu-b]

Like rustc, clang uses LLVM. I think that therefore it should be possible to inline functions from the clang output into rustc output using LLVM LTO. Would this be possible to implement?

[alexcrichton]

I think this may theoretically be possible, but in practice there are likely a lot of issues to arise due to differing LLVM versions. In any case I don't think this is somethign this crate will do automatically, so I'm going to close this.

[no-longer-on-githu-b]

Thanks!

[elichai]

http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html?m=1
@alexcrichton Any news on it now that it's technically possible? or does it require rust-lang/rust#64191 to do it cleanly? (if you don't think there are any missing pieces I can try and PR it here. the only problem I got in doing this manually is getting clang and rustc to have the same llvm version)

[froydnj]

Any news on it now that it's technically possible? or does it require rust-lang/rust#64191 to do it cleanly? (if you don't think there are any missing pieces I can try and PR it here. the only problem I got in doing this manually is getting clang and rustc to have the same llvm version)

As the person who implemented a lot of the Firefox side of cross-language LTO, I would strongly recommend not doing this automatically. xLTO is broken by the Mac linker in easy-to-hit ways, which immediately rules out a whole platform for this sort of work. (Firefox made it work, but we also cross-compile from Linux and fixed the bug in the open-source version of the Mac linker; the first is not viable for many people and asking people to compile and use a fixed linker is also not realistic.) The version mismatch thing was already mentioned in the above discussion, and I think trying to get that right in cc -- even to the point of not having terrible error messages -- is liable to be a much larger amount of code than adding the necessary flags.

Even an .enable_xlto_and_you_get_to_keep_the_broken_pieces() option faces a lot of uphill battle (update all the crates that depend on cc, expose it in a semi-uniform way from all of them, make the reverse-dependent crates turn on the correct option, and repeat...).

[alexcrichton]

I would agree with @froydnj that this is pretty unlikely to ever be turned on by default. I think exploring various options for turning it on explicitly can be explored, be it a method-per-crate or something like an env var. It would always be opt-in, however.

[elichai]

Opt in is obviously the right choice.
The question is if we can make it easier to use and if so does this need/can to anything to make it easier.

Currently with my testing the biggest problems are making sure the llvm version matches and that it's using the correct linker.