[PATCH] gcov: use mmap pools for KVP.

Martin Liška mliska@suse.cz
Tue Feb 9 08:37:12 GMT 2021


PING^2

@Honza: ?

On 1/29/21 2:33 PM, Martin Liška wrote:
> PING^1
> 
> On 1/25/21 1:51 PM, Martin Liška wrote:
>> On 1/22/21 3:33 PM, Jan Hubicka wrote:
>>>>> It is definitly doable (gcov machinery is quite flexible WRT having more
>>>>> types of counters).
>>>>
>>>> Yes, that would introduce back the dropped TOPN counters which I intentionally
>>>> dropped.
>>>
>>> We could bring back topn counters or the easier dominating vlaue ones
>>> and add command line option.  However perhaps better in long term would
>>> be keep adding mmap ifdefs for targets where it is important...
>>>
>>> Kernel guys seems to be getting on profile feedback with clang, so we
>>> should keep in mind posibility of supporting that as well.
>>
>> Sure, that should not be so difficult. They should handle it in their kernel
>> run-time.
>>
>>>>
>>>>>   We could however also ask users to either resort to
>>>>> -fno-profile-values or implement mmap equivalent ifdefs to libgcov if
>>>>> they really care about malloc profiling.
>>>>
>>>> Seems reasonable to me.
>>>>
>>>> Well, the current approach makes some assumptions on mmap (and malloc), but
>>>> they seem reasonable to me. I don't expect anybody building Mingw Firefox PGO build,
>>>> it's likely unsupported configuration.
>>>
>>> It is possible to build Firefox with mingw on windows and I would
>>> expected feedback to work.
>>> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_Mozilla_With_Mingw
>>> However this is not only about Firefox - we notice problems with Firefox
>>> since it is only real word app where we look at PGO more systematically.
>>> But we definitly should aim for PGO to be useful for apps of similar
>>> complexity.  It would be nice to incrase this testing coverage.
>>
>> I see.
>>
>>>
>>>>
>>>> Another observation about the tcmalloc 'malloc' implementation. It hangs in a PGO build,
>>>> but libgcov would be happy if NULL would be returned.
>>>
>>> Yep, I would expect other folks to try to PGO optimize malloc
>>> implementations an we could run into variety of issues...
>>
>> Ok, can we go with the suggested mmap patch for now?
>>
>> Thanks,
>> Martin
>>
>>>
>>> Honza
>>>>
>>>> Martin
>>>>
>>>>>
>>>>> So personally I do not see this as a must feature (and I think Martin
>>>>> was really looking forward to drop the former topn profile
>>>>> implementation :)
>>>>>
>>>>> Another intersting case would be, of course, profiling of kernel...
>>>>>
>>>>> Honza
>>>>>
>>>>
>>
> 



More information about the Gcc-patches mailing list