| Message ID | CAO2gOZVS5z0KJcsWj87d1ri+GJN50Ye=gGi7bZ+yikWhCi3iog@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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);
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
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
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
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
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
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);