This is the mail archive of the
mailing list for the GCC project.
Re: FDO and source changes
- From: Jeff Law <law at redhat dot com>
- To: Xinliang David Li <davidxl at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Jan Hubicka <hubicka at ucw dot cz>
- Date: Tue, 22 Jul 2014 21:14:30 -0600
- Subject: Re: FDO and source changes
- Authentication-results: sourceware.org; auth=none
- References: <CAAkRFZ+_sgKGZj07qbkvcw3Emm3Dzmhr0LtLdvnx4nTw2grG=g at mail dot gmail dot com>
On 07/16/14 14:32, Xinliang David Li wrote:
Is there a good reason why we would want to ever use the internal id?
Is it because the internal id shows up in the profile data for
Instrumentation based FDO is designed to work when the source files
that are used to generate the instr binary match exactly with the
sources in profile-use compile. It is known historically that using
stale profile (due to source changes, not gcda format change) can lead
to lots of mismatch warnings and even worse -- compiler ICEs. This is
due to two reasons:
1) the profile lookup for each function is based on funcdef_no which
can change when function definition order is changed or new functions
are inserted in the middle of a source
2) the indirect call target id may change due to source changes:
before GCC4.9, the id uses cgraph uid which is as bad as funcdef_no.
Attributing wrong IC target to the indirect call site is the main
cause of compiler ICE (we have signature match check, but bad target
can leak through result in problem later). Starting from gcc49, the
indirect target profiling uses profile_id which is stable for public
This patch introduces a new parameter for FDO to determine whether to
use internal id or assembler name based external id for profile
lookup. When the external id is used, GCC FDO will become very
tolerant to simple source changes.
Note that autoFDO solves this problem but it is currently limited to
Intel platforms with LBR support.
(Tested with SPEC, SPEC06 and large internal benchmarks. No performance impact).
Ok for trunk?
Given that we need both, why is this a param vs a regular -f option?
Shouldn't the default be to use the external id?
BTW, thanks for working on this. I've certainly got customers that want
to see the FDO data be more tolerant of changes.