[PATCH] D56015: Allow new comdat symbols to be added as a result of LTO.

[Peter Collingbourne via Phabricator via llvm-commits]

pcc added a comment.

> Why LTO optimization passes should not add new comdat variables? 
>  I don't see a reason for this.

This is necessary so that all symbol resolution can be done in the linker before LTO, which as a general principle is what the resolution-based LTO API tries to do (IIRC when the gold plugin was changed to use the linker's symbol resolutions that ended up fixing a lot of bugs, and the same principle was used to design the new LTO API). Resolving comdats again after LTO wouldn't entirely solve the problem, I believe: I expect that you'd still hit a duplicate symbol error if the linker is passed bitcode files together with a regular object file with the PGO instrumentation information.

> For my use case, I create a comdat variable to encoce PGO instrumentation information (format, version etc) in each module.
>  I rely linker to pick one definition. This pass is now in lto backend.

Can you add the comdat in a pass that runs at compile time?


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

https://reviews.llvm.org/D56015