[PATCH] D130229: [ELF] Add --thinlto-index= and --remapping-file=

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 22 06:28:37 PDT 2022


tejohnson added a comment.

In D130229#3670852 <https://reviews.llvm.org/D130229#3670852>, @wenlei wrote:

> In D130229#3670843 <https://reviews.llvm.org/D130229#3670843>, @MaskRay wrote:
>
>> In D130229#3670802 <https://reviews.llvm.org/D130229#3670802>, @wenlei wrote:
>>
>>> I'm not sure how this solution works because symbol resolution before and after importing aren't guaranteed to produce same result even if input order is identical.
>>>
>>> Say we have foo in a.o, which references bar in b.o (lazy object). Assuming a.o imports bar, before importing, b.o gets picked because of that foo->bar reference, but the reference will be gone after importing and we may not pick b.o during final linking. The ripple effect from dropping b.o can disturb other symbol's resolution, making final link and thin link diverge.
>>
>> Imported functions have available_externally linkage and are not considered definitions in the IR symbol table. There is no symbol resolution difference in your example.
>
> I actually meant importing + inlining. After importing and inlining foo->bar, the reference to bar will be gone in a.o output from thinlto codegen, so the input for final linking won't see the reference for bar, right? Does that not change final linking symbol resolution still?

This is my concern too. See discussion on https://reviews.llvm.org/D22356 (there's more discussion on llvm-commits that didn't make it into phab somehow), and the test case included there. That approach was abandoned in favor of the params file based on the extensive discussion there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130229



More information about the llvm-commits mailing list