This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] libgcov.c re-factoring and offline profile-tool
- From: Xinliang David Li <davidxl at google dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Rong Xu <xur at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 5 Nov 2013 08:58:45 -0800
- Subject: Re: [RFC] libgcov.c re-factoring and offline profile-tool
- Authentication-results: sourceware.org; auth=none
- References: <CAF1bQ=Qy6--WX-bLYZ8aWXjVVu4pW-H3U+PkATgXwg5c7MZsBg at mail dot gmail dot com> <CAAkRFZ+-tLZqUNQRtu7jN3d3BYG8oi-+q0J6pkduHp5GS3oTkQ at mail dot gmail dot com> <20131104095529 dot GB28992 at kam dot mff dot cuni dot cz> <CAF1bQ=THYY8NqoJ0XDYxnFS9=j9P6-5nLwA6nX1bA+0v1zmUoQ at mail dot gmail dot com> <CAAkRFZK-AoS4eKBnoNciHeq5kn5sP60rqyV1dVZVaBte1aW-ew at mail dot gmail dot com> <20131105091850 dot GB13502 at kam dot mff dot cuni dot cz> <20131105092344 dot GF27813 at tucnak dot zalov dot cz>
Those functions are not referencing each other, but they get used in
different logical groups, so at least control granularity can be
improved. For instance,
1) all gcov user interfaces such as gcov_dump, gcov_flush, gcov_reset
are either not used at all, or all of them are used -- there is no
need to split this group. After Rong's refactoring (move them into a
separate file), the guarding macro can be removed for them
2) _gcov_merge_add is used by 4 different profilers, so it is almost
always linked in
It is unclear how other value profilers are used on other targets. For
x86, they are on by default, so the profiler bodies and merge
functions are also always linked in.
David
On Tue, Nov 5, 2013 at 1:23 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Nov 05, 2013 at 10:18:50AM +0100, Jan Hubicka wrote:
>> > I wonder if it makes sense to get rid of the conditional compile such as
>> >
>> > #ifdef L_gcov_xxxxx
>> > ..
>> >
>> > #endif
>> >
>> > This has the advantage of producing slightly smaller instrumented
>> > binary, but this benefit can also be achieved via -ffunction-sections
>> > and let linker to garbage collect unused functions.
>> >
>> > (probably as a follow up if it makes sense).
>>
>> I believe we use this funny scheme primarily for targets that have no function
>> section support (and also the hand made splitting can be more sane).
>> For a low-level library like libgcov is that is supposed to have small footprint,
>> I guess the current scheme is resonable thing to do....
>
> I think the #ifdef L* stuff is there mainly so that we have small
> granularity in the *.a libraries (one function per object file), so that one
> links only what is really required (at least, that is why libgcc.a does
> that). Of course, if there are many interdependencies between the functions
> and you always essentially link in everything, the usefulness of that is
> lower.
>
> Jakub