tree f312a2dc615911d011dc26a3bde9c01188624431
parent 41ede3aede2249a614e6081f8a44a756f6019aae
author Tom Stellard <tstellar@redhat.com> 1571111426 +0000
committer Tom Stellard <tstellar@redhat.com> 1571111426 +0000

Merging r372020 and r372182:

------------------------------------------------------------------------
r372020 | rnk | 2019-09-16 11:49:09 -0700 (Mon, 16 Sep 2019) | 30 lines

[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
------------------------------------------------------------------------

------------------------------------------------------------------------
r372182 | rnk | 2019-09-17 14:10:49 -0700 (Tue, 17 Sep 2019) | 12 lines

[PGO] Don't use comdat groups for counters & data on COFF

For COFF, a comdat group is really a symbol marked
IMAGE_COMDAT_SELECT_ANY and zero or more other symbols marked
IMAGE_COMDAT_SELECT_ASSOCIATIVE. Typically the associative symbols in
the group are not external and are not referenced by other TUs, they are
things like debug info, C++ dynamic initializers, or other section
registration schemes. The Visual C++ linker reports a duplicate symbol
error for symbols marked IMAGE_COMDAT_SELECT_ASSOCIATIVE even if they
would be discarded after handling the leader symbol.

Fixes coverage-inline.cpp in check-profile after r372020.
------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_90@374858 91177308-0d34-0410-b5e6-96231b3b80d8