[PATCH] D152973: [gold] Add preliminary FatLTO support to the Gold plugin

[Paul Kirth via Phabricator via llvm-commits]

paulkirth added a comment.

In D152973#4520240 <https://reviews.llvm.org/D152973#4520240>, @nikic wrote:

> In D152973#4519148 <https://reviews.llvm.org/D152973#4519148>, @paulkirth wrote:
>
>> @tbaeder, could you provide a bit more information about the configuration you are using? The test is in an x86 directory, which should mean it only runs on x86 enabled targets, right? If this is blocking you, I'm OK w/ a revert, but do want to understand what the issue is.
>
> The test requires not only the x86 target in LLVM, but also that ld.gold supports it, which will generally only be the case on x86 hosts. So I think the test needs something like `REQUIRES: x86_64-linux` (not sure if that's the right spelling...).

I see. Thank you for pointing that out.  I think I may just revert this for now while we hash out the potential issues downstream.

>> @peter.smith thank you for pointing that out. I will be sure to update the documentation.
>
> FYI this change also broke Rust LTO for the same reason (`.llvmbc` used for its own fat LTO equivalent). I expect that can be fixed by switching it to use `.llvm.lto`, but not sure if that will cause any other issues.

Hmm, I wasn't aware that `rustc` used a `.llvmbc` section. Thanks for pointing this out .The initial discussion on discourse pointed out that `.llvmbc` was only added to support the apple use case (discussion on this point starts roughly here https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977/3), and non-lto usage should go away. We moved to a `.llvm.lto` section to make the distinction clear that this was LTO compatible bitcode and not just whatever the frontend emitted.

In your opinion, do we need a soft transition here? If so, any advice on what that should look like would be helpful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152973