Patchwork [Google] Suppress message when primary module entry cannot found

login
register
mail settings
Submitter Dehao Chen
Date May 10, 2013, 5:37 p.m.
Message ID <CAO2gOZVS5z0KJcsWj87d1ri+GJN50Ye=gGi7bZ+yikWhCi3iog@mail.gmail.com>
Download mbox | patch
Permalink /patch/243051/
State New
Headers show

Comments

Dehao Chen - May 10, 2013, 5:37 p.m.
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
Teresa Johnson - May 10, 2013, 5:47 p.m.
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);
Dehao Chen - May 10, 2013, 6 p.m.
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
Xinliang David Li - May 10, 2013, 6:03 p.m.
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
Teresa Johnson - May 10, 2013, 6:32 p.m.
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
Dehao Chen - May 10, 2013, 6:37 p.m.
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
Dehao Chen - May 10, 2013, 6:42 p.m.
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

Patch

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);