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

Wei Wang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 2 02:52:48 PDT 2022


weiwang added a comment.

> The current implicit ThinLTO takes the simplest approach by inserting lto.tmp at the end, breaking ordering.
> I don't think the scheme is set in stone and changing distributed ThinLTO to behave like it is probably not the right direction.
> On the other hand, it's non-trivial to fix its ordering. Therefore, I think making distributed ThinLTO and implicit ThinLTO have very similar symbol resolution behaviors is a stretch goal. If --thinlto-index= doesn't behave like implicit ThinLTO, I don't think it is a design flaw.

My understanding is that inserting `lto.tmp` at the end shouldn't matter to the symbol resolution order. Bitcode objects, before going through compilation, have already gone through symbol resolution, so there shouldn't be new symbols introduced when `lto.tmp` is inserted, except those being promoted or created internally by llvm, but those symbols is unique to the module.

We are currently in the process of deprecating the use of regular archives in favor of thin archives in our build system. This would make it much easier to include both bitcode and prebuilt native objects into the index list. And we'd like to propose another solution just to do that https://reviews.llvm.org/D130975. The included test case shows an example where the current `--thinlto-index-only=` does not give a clear indication of how to keep the symbol resolution order consistent between thin link and final link.

     


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