* [Google] Suppress message when primary module entry cannot found @ 2013-05-10 17:37 Dehao Chen 2013-05-10 17:47 ` Teresa Johnson 0 siblings, 1 reply; 7+ messages in thread From: Dehao Chen @ 2013-05-10 17:37 UTC (permalink / raw) To: GCC Patches; +Cc: David Li Now we don't store the module info if the module is not exported or has any aux module (to compress the profile data size). Thus it's normal that a primary module entry cannot be found. This patch suppresses the messages printed when the primary module is not found. Bootstrapped and passed regression test. OK for google branch? Thanks, Dehao Index: auto-profile.c =================================================================== --- auto-profile.c (revision 198751) +++ auto-profile.c (working copy) @@ -497,10 +497,7 @@ read_aux_modules (void) module.name = xstrdup (in_fnames[0]); entry = (struct afdo_module *) htab_find (module_htab, &module); if (!entry) - { - inform (0, "primary module %s cannot be found.", in_fnames[0]); - return; - } + return; module_infos = XCNEWVEC (struct gcov_module_info *, entry->num_aux_modules + 1); afdo_add_module (module_infos, entry, true); ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Google] Suppress message when primary module entry cannot found 2013-05-10 17:37 [Google] Suppress message when primary module entry cannot found Dehao Chen @ 2013-05-10 17:47 ` Teresa Johnson 2013-05-10 18:00 ` Dehao Chen 0 siblings, 1 reply; 7+ messages in thread From: Teresa Johnson @ 2013-05-10 17:47 UTC (permalink / raw) To: Dehao Chen; +Cc: GCC Patches, David Li Is it only auto fdo that doesn't store the module info if the module is not exported or has aux modules? Note that this will prevent usage of my script that enables annotation of gcov dump info with function names, which relies on accessing the primary module info to obtain the module name (which is then used to locate the module's associated func id to func name mapping optionally emitted into the build output). Teresa On Fri, May 10, 2013 at 10:37 AM, Dehao Chen <dehao@google.com> wrote: > Now we don't store the module info if the module is not exported or > has any aux module (to compress the profile data size). Thus it's > normal that a primary module entry cannot be found. This patch > suppresses the messages printed when the primary module is not found. > > Bootstrapped and passed regression test. > > OK for google branch? > > Thanks, > Dehao > > Index: auto-profile.c > =================================================================== > --- auto-profile.c (revision 198751) > +++ auto-profile.c (working copy) > @@ -497,10 +497,7 @@ read_aux_modules (void) > module.name = xstrdup (in_fnames[0]); > entry = (struct afdo_module *) htab_find (module_htab, &module); > if (!entry) > - { > - inform (0, "primary module %s cannot be found.", in_fnames[0]); > - return; > - } > + return; > module_infos = XCNEWVEC (struct gcov_module_info *, > entry->num_aux_modules + 1); > afdo_add_module (module_infos, entry, true); -- Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Google] Suppress message when primary module entry cannot found 2013-05-10 17:47 ` Teresa Johnson @ 2013-05-10 18:00 ` Dehao Chen 2013-05-10 18:03 ` Xinliang David Li 2013-05-10 18:32 ` Teresa Johnson 0 siblings, 2 replies; 7+ messages in thread From: Dehao Chen @ 2013-05-10 18:00 UTC (permalink / raw) To: Teresa Johnson; +Cc: GCC Patches, David Li On Fri, May 10, 2013 at 10:47 AM, Teresa Johnson <tejohnson@google.com> wrote: > Is it only auto fdo that doesn't store the module info if the module > is not exported or has aux modules? Note that this will prevent usage > of my script that enables annotation of gcov dump info with function > names, which relies on accessing the primary module info to obtain the > module name (which is then used to locate the module's associated func > id to func name mapping optionally emitted into the build output). Yes, this is auto fdo only. And gcov dump will not work on auto fdo profile because it does not use the id at all in the profile (instead, it stores the function name directly). Thanks, Dehao > > Teresa > > On Fri, May 10, 2013 at 10:37 AM, Dehao Chen <dehao@google.com> wrote: >> Now we don't store the module info if the module is not exported or >> has any aux module (to compress the profile data size). Thus it's >> normal that a primary module entry cannot be found. This patch >> suppresses the messages printed when the primary module is not found. >> >> Bootstrapped and passed regression test. >> >> OK for google branch? >> >> Thanks, >> Dehao >> >> Index: auto-profile.c >> =================================================================== >> --- auto-profile.c (revision 198751) >> +++ auto-profile.c (working copy) >> @@ -497,10 +497,7 @@ read_aux_modules (void) >> module.name = xstrdup (in_fnames[0]); >> entry = (struct afdo_module *) htab_find (module_htab, &module); >> if (!entry) >> - { >> - inform (0, "primary module %s cannot be found.", in_fnames[0]); >> - return; >> - } >> + return; >> module_infos = XCNEWVEC (struct gcov_module_info *, >> entry->num_aux_modules + 1); >> afdo_add_module (module_infos, entry, true); > > > > -- > Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Google] Suppress message when primary module entry cannot found 2013-05-10 18:00 ` Dehao Chen @ 2013-05-10 18:03 ` Xinliang David Li 2013-05-10 18:37 ` Dehao Chen 2013-05-10 18:32 ` Teresa Johnson 1 sibling, 1 reply; 7+ messages in thread From: Xinliang David Li @ 2013-05-10 18:03 UTC (permalink / raw) To: Dehao Chen; +Cc: Teresa Johnson, GCC Patches ok. Would be nicer if there is a way to tell this from other error cases though. David On Fri, May 10, 2013 at 11:00 AM, Dehao Chen <dehao@google.com> wrote: > On Fri, May 10, 2013 at 10:47 AM, Teresa Johnson <tejohnson@google.com> wrote: >> Is it only auto fdo that doesn't store the module info if the module >> is not exported or has aux modules? Note that this will prevent usage >> of my script that enables annotation of gcov dump info with function >> names, which relies on accessing the primary module info to obtain the >> module name (which is then used to locate the module's associated func >> id to func name mapping optionally emitted into the build output). > > Yes, this is auto fdo only. And gcov dump will not work on auto fdo > profile because it does not use the id at all in the profile (instead, > it stores the function name directly). > > Thanks, > Dehao > >> >> Teresa >> >> On Fri, May 10, 2013 at 10:37 AM, Dehao Chen <dehao@google.com> wrote: >>> Now we don't store the module info if the module is not exported or >>> has any aux module (to compress the profile data size). Thus it's >>> normal that a primary module entry cannot be found. This patch >>> suppresses the messages printed when the primary module is not found. >>> >>> Bootstrapped and passed regression test. >>> >>> OK for google branch? >>> >>> Thanks, >>> Dehao >>> >>> Index: auto-profile.c >>> =================================================================== >>> --- auto-profile.c (revision 198751) >>> +++ auto-profile.c (working copy) >>> @@ -497,10 +497,7 @@ read_aux_modules (void) >>> module.name = xstrdup (in_fnames[0]); >>> entry = (struct afdo_module *) htab_find (module_htab, &module); >>> if (!entry) >>> - { >>> - inform (0, "primary module %s cannot be found.", in_fnames[0]); >>> - return; >>> - } >>> + return; >>> module_infos = XCNEWVEC (struct gcov_module_info *, >>> entry->num_aux_modules + 1); >>> afdo_add_module (module_infos, entry, true); >> >> >> >> -- >> Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Google] Suppress message when primary module entry cannot found 2013-05-10 18:03 ` Xinliang David Li @ 2013-05-10 18:37 ` Dehao Chen 0 siblings, 0 replies; 7+ messages in thread From: Dehao Chen @ 2013-05-10 18:37 UTC (permalink / raw) To: Xinliang David Li; +Cc: Teresa Johnson, GCC Patches Right now, the error was prevented from the profile_creation tool side. In GCC, we only assume that the all exported modules will have primary module entry stored in profile. We can also check it when reading in profile, but that might be too costly because every compilation (even for those files that do not have profile) will iterate all module info table to check if it's exported. Thanks, Dehao On Fri, May 10, 2013 at 11:03 AM, Xinliang David Li <davidxl@google.com> wrote: > ok. Would be nicer if there is a way to tell this from other error cases though. > > David > > On Fri, May 10, 2013 at 11:00 AM, Dehao Chen <dehao@google.com> wrote: >> On Fri, May 10, 2013 at 10:47 AM, Teresa Johnson <tejohnson@google.com> wrote: >>> Is it only auto fdo that doesn't store the module info if the module >>> is not exported or has aux modules? Note that this will prevent usage >>> of my script that enables annotation of gcov dump info with function >>> names, which relies on accessing the primary module info to obtain the >>> module name (which is then used to locate the module's associated func >>> id to func name mapping optionally emitted into the build output). >> >> Yes, this is auto fdo only. And gcov dump will not work on auto fdo >> profile because it does not use the id at all in the profile (instead, >> it stores the function name directly). >> >> Thanks, >> Dehao >> >>> >>> Teresa >>> >>> On Fri, May 10, 2013 at 10:37 AM, Dehao Chen <dehao@google.com> wrote: >>>> Now we don't store the module info if the module is not exported or >>>> has any aux module (to compress the profile data size). Thus it's >>>> normal that a primary module entry cannot be found. This patch >>>> suppresses the messages printed when the primary module is not found. >>>> >>>> Bootstrapped and passed regression test. >>>> >>>> OK for google branch? >>>> >>>> Thanks, >>>> Dehao >>>> >>>> Index: auto-profile.c >>>> =================================================================== >>>> --- auto-profile.c (revision 198751) >>>> +++ auto-profile.c (working copy) >>>> @@ -497,10 +497,7 @@ read_aux_modules (void) >>>> module.name = xstrdup (in_fnames[0]); >>>> entry = (struct afdo_module *) htab_find (module_htab, &module); >>>> if (!entry) >>>> - { >>>> - inform (0, "primary module %s cannot be found.", in_fnames[0]); >>>> - return; >>>> - } >>>> + return; >>>> module_infos = XCNEWVEC (struct gcov_module_info *, >>>> entry->num_aux_modules + 1); >>>> afdo_add_module (module_infos, entry, true); >>> >>> >>> >>> -- >>> Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Google] Suppress message when primary module entry cannot found 2013-05-10 18:00 ` Dehao Chen 2013-05-10 18:03 ` Xinliang David Li @ 2013-05-10 18:32 ` Teresa Johnson 2013-05-10 18:42 ` Dehao Chen 1 sibling, 1 reply; 7+ messages in thread From: Teresa Johnson @ 2013-05-10 18:32 UTC (permalink / raw) To: Dehao Chen; +Cc: GCC Patches, David Li On Fri, May 10, 2013 at 11:00 AM, Dehao Chen <dehao@google.com> wrote: > On Fri, May 10, 2013 at 10:47 AM, Teresa Johnson <tejohnson@google.com> wrote: >> Is it only auto fdo that doesn't store the module info if the module >> is not exported or has aux modules? Note that this will prevent usage >> of my script that enables annotation of gcov dump info with function >> names, which relies on accessing the primary module info to obtain the >> module name (which is then used to locate the module's associated func >> id to func name mapping optionally emitted into the build output). > > Yes, this is auto fdo only. And gcov dump will not work on auto fdo > profile because it does not use the id at all in the profile (instead, > it stores the function name directly). If you are trying to reduce profile sizes, it might be worthwhile to try to use the id instead of the name. Before implementing the wrapper script solution to getting function names in the gcov-info dump I first made a patch to include the function names in the gcda file. This caused a huge bloat in gcda and instrumented file sizes. Teresa > > Thanks, > Dehao > >> >> Teresa >> >> On Fri, May 10, 2013 at 10:37 AM, Dehao Chen <dehao@google.com> wrote: >>> Now we don't store the module info if the module is not exported or >>> has any aux module (to compress the profile data size). Thus it's >>> normal that a primary module entry cannot be found. This patch >>> suppresses the messages printed when the primary module is not found. >>> >>> Bootstrapped and passed regression test. >>> >>> OK for google branch? >>> >>> Thanks, >>> Dehao >>> >>> Index: auto-profile.c >>> =================================================================== >>> --- auto-profile.c (revision 198751) >>> +++ auto-profile.c (working copy) >>> @@ -497,10 +497,7 @@ read_aux_modules (void) >>> module.name = xstrdup (in_fnames[0]); >>> entry = (struct afdo_module *) htab_find (module_htab, &module); >>> if (!entry) >>> - { >>> - inform (0, "primary module %s cannot be found.", in_fnames[0]); >>> - return; >>> - } >>> + return; >>> module_infos = XCNEWVEC (struct gcov_module_info *, >>> entry->num_aux_modules + 1); >>> afdo_add_module (module_infos, entry, true); >> >> >> >> -- >> Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413 -- Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Google] Suppress message when primary module entry cannot found 2013-05-10 18:32 ` Teresa Johnson @ 2013-05-10 18:42 ` Dehao Chen 0 siblings, 0 replies; 7+ messages in thread From: Dehao Chen @ 2013-05-10 18:42 UTC (permalink / raw) To: Teresa Johnson; +Cc: GCC Patches, David Li On Fri, May 10, 2013 at 11:32 AM, Teresa Johnson <tejohnson@google.com> wrote: > On Fri, May 10, 2013 at 11:00 AM, Dehao Chen <dehao@google.com> wrote: >> On Fri, May 10, 2013 at 10:47 AM, Teresa Johnson <tejohnson@google.com> wrote: >>> Is it only auto fdo that doesn't store the module info if the module >>> is not exported or has aux modules? Note that this will prevent usage >>> of my script that enables annotation of gcov dump info with function >>> names, which relies on accessing the primary module info to obtain the >>> module name (which is then used to locate the module's associated func >>> id to func name mapping optionally emitted into the build output). >> >> Yes, this is auto fdo only. And gcov dump will not work on auto fdo >> profile because it does not use the id at all in the profile (instead, >> it stores the function name directly). > > If you are trying to reduce profile sizes, it might be worthwhile to > try to use the id instead of the name. Before implementing the wrapper > script solution to getting function names in the gcov-info dump I > first made a patch to include the function names in the gcda file. > This caused a huge bloat in gcda and instrumented file sizes. In AutoFDO, we use names (file names, function names) to match the binary level profile back to source. We do this because: 1. We don't do instrumentation, thus there is no id info in the binary/profile 2. This makes the profile loosely coupled with profile collection runs For the size issue, we only stores profile for those functions with sample counts larger than a threshold. Right now, a typical profile file is around 10M~20M. Thanks, Dehao > > Teresa > >> >> Thanks, >> Dehao >> >>> >>> Teresa >>> >>> On Fri, May 10, 2013 at 10:37 AM, Dehao Chen <dehao@google.com> wrote: >>>> Now we don't store the module info if the module is not exported or >>>> has any aux module (to compress the profile data size). Thus it's >>>> normal that a primary module entry cannot be found. This patch >>>> suppresses the messages printed when the primary module is not found. >>>> >>>> Bootstrapped and passed regression test. >>>> >>>> OK for google branch? >>>> >>>> Thanks, >>>> Dehao >>>> >>>> Index: auto-profile.c >>>> =================================================================== >>>> --- auto-profile.c (revision 198751) >>>> +++ auto-profile.c (working copy) >>>> @@ -497,10 +497,7 @@ read_aux_modules (void) >>>> module.name = xstrdup (in_fnames[0]); >>>> entry = (struct afdo_module *) htab_find (module_htab, &module); >>>> if (!entry) >>>> - { >>>> - inform (0, "primary module %s cannot be found.", in_fnames[0]); >>>> - return; >>>> - } >>>> + return; >>>> module_infos = XCNEWVEC (struct gcov_module_info *, >>>> entry->num_aux_modules + 1); >>>> afdo_add_module (module_infos, entry, true); >>> >>> >>> >>> -- >>> Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413 > > > > -- > Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-05-10 18:42 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-05-10 17:37 [Google] Suppress message when primary module entry cannot found Dehao Chen 2013-05-10 17:47 ` Teresa Johnson 2013-05-10 18:00 ` Dehao Chen 2013-05-10 18:03 ` Xinliang David Li 2013-05-10 18:37 ` Dehao Chen 2013-05-10 18:32 ` Teresa Johnson 2013-05-10 18:42 ` Dehao Chen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).