public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [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: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: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: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).