This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: FDO and source changes
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Xinliang David Li <davidxl at google dot com>
- Cc: Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jan Hubicka <hubicka at ucw dot cz>
- Date: Wed, 23 Jul 2014 20:06:14 +0200
- Subject: Re: FDO and source changes
- Authentication-results: sourceware.org; auth=none
- References: <CAAkRFZ+_sgKGZj07qbkvcw3Emm3Dzmhr0LtLdvnx4nTw2grG=g at mail dot gmail dot com> <53CF2896 dot 1060300 at redhat dot com> <CAAkRFZKa6BY6PFwTaH=EYcUnSf-3yvEj76_8G_tCFUOamTrQLQ at mail dot gmail dot com>
>
> I don't think existing profile data matter.
>
> For perfect fresh profile, using external id has the chance of
> collision. I have tested with a C++ symbol file with about 750k unique
> symbol names, using crc32 based id yields 71 collisions --- the rate
> is ~0.009%.
init_node_map will resolve profile_id conflicts within single unit, so this is
not causing any troubles (naturally the profile will read wose if one of the
two conflicting symbols disappears, but that is an minor issue).
So i think we want to go for profile_id by default.
Only what I am concerned about is to make C static functions that have same name in
different translation units to not clash in profile_id or indirect call optimization
will be behaving poorly. That is main reason why we mix in global symbol name.
As mentioned in the original review, I think using gcov file name should be good enough...
Honza
>
> >
> > 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?
> >
>
> I am open to both. I have not seen evidence that id collision causes
> trouble even though in theory it can.
>
> thanks,
>
> David
>
>
> > BTW, thanks for working on this. I've certainly got customers that want to
> > see the FDO data be more tolerant of changes.
> >
> > Heff
> >