This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Google/4_8] LIPO COMDAT profile fixups
- From: Teresa Johnson <tejohnson at google dot com>
- To: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, David Li <davidxl at google dot com>
- Cc: Rong Xu <xur at google dot com>
- Date: Mon, 19 May 2014 22:08:13 -0700
- Subject: Re: [Google/4_8] LIPO COMDAT profile fixups
- Authentication-results: sourceware.org; auth=none
- References: <CAAe5K+UkRzc42LWqO2kMQ8FUyn-q1yLe6___VvVf4V8i-_ixSA at mail dot gmail dot com>
Ping.
Teresa
On Wed, May 14, 2014 at 4:39 PM, Teresa Johnson <tejohnson@google.com> wrote:
> This patch applies profile fixups to COMDATs on the dyn ipa callgraph
> at the end of LIPO module grouping (either in the profile gen run or
> in gcov-tool). This is to address issues with missing profiles in the
> out-of-line COMDAT copies not selected by the linker, and indirect
> call profiles that target a module not included in the module group.
> By default, both fixups are enabled, but can be controlled by a
> profile-gen parameter, an environment variable, and a gcov-tool
> option.
>
> The fixups assume that functions with the same lineno and cfg checksum
> are copies of the same COMDAT. This is made more likely by ensuring
> that in LIPO mode we include the full mangled name in the
> lineno_checksum.
>
> For the counter fixup, we merge all non-zero profiles with matching
> checksums and copy the merged profile into copies with all-zero
> profiles.
>
> For the indirect counter fixup, if an indirect call profile target is
> not in the module group, we look for a matching checksum copy in the
> primary module and if exactly one is found we change the target to
> that.
>
> If any fixups are applied, the gcda files are rewritten after module grouping.
>
> This also required a couple of other changes to the optimizer. During
> cgraph node resolution, we were arbitrarily selecting a copy that had
> non-zero profiles. Now there are many more to choose from, so we will
> prefer the primary module copy if it is non-zero. Also, during cloning
> for inlining, we only want to update the profile on the callee node if
> we are inlining into the resolved node caller node. We were already
> doing this for AutoFDO, and need to do this here now that many node
> copies have the same profile.
>
> Patch attached. Tested with regression tests and internal benchmarks.
> Ok for google branches?
>
> Thanks,
> Teresa
>
>
>
> --
> Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413
--
Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413