FailedChanges

Summary

  1. [LTO][Legacy] Add new C inferface to query libcall functions Summary: This is needed to implemented the same approach as lld (implemented in r338434) for how to handling symbols that can be generated by LTO code generator but not present in the symbol table for linker that uses legacy C APIs. libLTO is in charge of providing the list of symbols. Linker is in charge of implementing the eager loading from static libraries using the list of symbols. rdar://problem/52853974 Reviewers: tejohnson, bd1976llvm, deadalnix, espindola Reviewed By: tejohnson Subscribers: emaste, arichardson, hiraditya, MaskRay, dang, kledzik, mehdi_amini, inglorion, jkorous, dexonsmith, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67568
  2. [PGO] Use linkonce_odr linkage for __profd_ variables in comdat groups This fixes relocations against __profd_ symbols in discarded sections, which is PR41380. In general, instrumentation happens very early, and optimization and inlining happens afterwards. The counters for a function are calculated early, and after inlining, counters for an inlined function may be widely referenced by other functions. For C++ inline functions of all kinds (linkonce_odr & available_externally mainly), instr profiling wants to deduplicate these __profc_ and __profd_ globals. Otherwise the binary would be quite large. I made __profd_ and __profc_ comdat in r355044, but I chose to make __profd_ internal. At the time, I was only dealing with coverage, and in that case, none of the instrumentation needs to reference __profd_. However, if you use PGO, then instrumentation passes add calls to __llvm_profile_instrument_range which reference __profd_ globals. The solution is to make these globals externally visible by using linkonce_odr linkage for data as was done for counters. This is safe because PGO adds a CFG hash to the names of the data and counter globals, so if different TUs have different globals, they will get different data and counter arrays. Reviewers: xur, hans Differential Revision: https://reviews.llvm.org/D67579
Revision 372021 by steven_wu:
[LTO][Legacy] Add new C inferface to query libcall functions

Summary:
This is needed to implemented the same approach as lld (implemented in r338434)
for how to handling symbols that can be generated by LTO code generator
but not present in the symbol table for linker that uses legacy C APIs.

libLTO is in charge of providing the list of symbols. Linker is in
charge of implementing the eager loading from static libraries using
the list of symbols.

rdar://problem/52853974

Reviewers: tejohnson, bd1976llvm, deadalnix, espindola

Reviewed By: tejohnson

Subscribers: emaste, arichardson, hiraditya, MaskRay, dang, kledzik, mehdi_amini, inglorion, jkorous, dexonsmith, ributzka, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D67568
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/include/llvm-c/lto.h (diff)llvm.src/include/llvm-c/lto.h
The file was modified/llvm/trunk/include/llvm/LTO/LTO.h (diff)llvm.src/include/llvm/LTO/LTO.h
The file was modified/llvm/trunk/lib/LTO/LTO.cpp (diff)llvm.src/lib/LTO/LTO.cpp
The file was modified/llvm/trunk/tools/lto/lto.cpp (diff)llvm.src/tools/lto/lto.cpp
The file was modified/llvm/trunk/tools/lto/lto.exports (diff)llvm.src/tools/lto/lto.exports
Revision 372020 by rnk:
[PGO] Use linkonce_odr linkage for __profd_ variables in comdat groups

This fixes relocations against __profd_ symbols in discarded sections,
which is PR41380.

In general, instrumentation happens very early, and optimization and
inlining happens afterwards. The counters for a function are calculated
early, and after inlining, counters for an inlined function may be
widely referenced by other functions.

For C++ inline functions of all kinds (linkonce_odr &
available_externally mainly), instr profiling wants to deduplicate these
__profc_ and __profd_ globals. Otherwise the binary would be quite
large.

I made __profd_ and __profc_ comdat in r355044, but I chose to make
__profd_ internal. At the time, I was only dealing with coverage, and in
that case, none of the instrumentation needs to reference __profd_.
However, if you use PGO, then instrumentation passes add calls to
__llvm_profile_instrument_range which reference __profd_ globals. The
solution is to make these globals externally visible by using
linkonce_odr linkage for data as was done for counters.

This is safe because PGO adds a CFG hash to the names of the data and
counter globals, so if different TUs have different globals, they will
get different data and counter arrays.

Reviewers: xur, hans

Differential Revision: https://reviews.llvm.org/D67579
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Transforms/Instrumentation/InstrProfiling.cpp (diff)llvm.src/lib/Transforms/Instrumentation/InstrProfiling.cpp
The file was modified/llvm/trunk/test/Instrumentation/InstrProfiling/PR23499.ll (diff)llvm.src/test/Instrumentation/InstrProfiling/PR23499.ll
The file was modified/llvm/trunk/test/Instrumentation/InstrProfiling/comdat.ll (diff)llvm.src/test/Instrumentation/InstrProfiling/comdat.ll
The file was modified/llvm/trunk/test/Instrumentation/InstrProfiling/linkage.ll (diff)llvm.src/test/Instrumentation/InstrProfiling/linkage.ll