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

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 13 19:04:52 PDT 2023


MaskRay added a comment.

In D152973#4498717 <https://reviews.llvm.org/D152973#4498717>, @paulkirth wrote:

> In D152973#4457524 <https://reviews.llvm.org/D152973#4457524>, @MaskRay wrote:
>
>> We probably should support `-?-plugin-opt=(no-)?fat-lto-objects`  to parallel the lld option.
>
> So, I'm not sure on that. On one hand, I think it makes sense from a consistency standpoint. On the other hand, the llvm gold plugin is already added when the user wants LTO, and will give select the bitcode sections for them. We added the `--(no-)fat-lto-objects` flag in LLD in part because there isn't an equivalent LTO on/off switch. Using the plugin at all seems to serve the same purpose to me.
>
> Also, I'm not really sure how/why that would be desirable. Is the idea so you can use regular (Thin)LTO objects + FatLTO objects, but only choose the `.text` of the fat object? In my experiments GCC would link the fat objects w/ LTO unless you passed `-fno-lto`, but maybe that isn't an important consideration.
>
> Supporting those meaningfully may also be a bit challenging, since it appears to me that we have less ability to change the behavior here than we do in LLD. But maybe I'm overthinking that part, and just plumbing a flag through to `InputFile::create`(and whatever else) is enough?

OK, if supporting avoiding LTO for a relocatable object file with `.llvm.lto` is too difficult, this change is fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152973



More information about the llvm-commits mailing list