[PATCH] D146776: [llvm] Preliminary fat-lto-objects support

Sat Jun 10 07:04:21 PDT 2023

tejohnson added a comment.

In D146776#4410967 <https://reviews.llvm.org/D146776#4410967>, @nikic wrote:

> I'm okay with the new approach -- I think it makes the feature somewhat less compelling, but it's the path of least resistance for now. However, I'd like to have it documented that we're explicitly not guaranteeing that the results are bit-for-bit identical, and this is just an artifact of the current implementation.
>
> Two notes on the larger feature:
>
> - I'm concerned about the lld-only limitation. Unless there is some technical limitation here, this should be supported in LLVMgold as well.

Great point. I see that the linker changes aren't in this patch, but in another related one. I agree it should be supported by the LLVM gold plugin as well, which should be straightforward. This can be another follow on patch. It looks like you would want to modify this change made to ignore the -fembed-bitcode sections so that we do in fact claim the fat object files:
https://github.com/llvm/llvm-project/blob/main/llvm/tools/gold/gold-plugin.cpp#L541-L547

> - It looks like this requires passing `-fat-lto-objects` to lld to actually get LTO -- and it looks like the clang doesn't do this itself even if `-ffat-lto-objects` is passed to the driver? Can you please check how these flags work in GCC? I'm not entirely confident on this, but I expect that if you have fat objects they will use LTO by default unless you pass `-fno-lto` to the driver. We should try to match whatever the GCC behavior is here.

agree

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146776/new/

https://reviews.llvm.org/D146776