Ok. The internal benchmark testing also shows no change in behavior.
David
On Fri, Jul 25, 2014 at 2:55 PM, Jeff Law wrote:
> On 07/23/14 15:52, Xinliang David Li wrote:
>>
>> Index: ChangeLog
>> ===
>> --- ChangeLog (revision 212
On 07/23/14 15:52, Xinliang David Li wrote:
Index: ChangeLog
===
--- ChangeLog (revision 212682)
+++ ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2014-07-16 Xinliang David Li
+
+ * params.def: New parameter.
+ * covera
On Wed, Jul 23, 2014 at 11:06 AM, Jan Hubicka wrote:
>>
>> I don't think existing profile data matter.
>>
>> For perfect fresh profile, using external id has the chance of
>> collision. I have tested with a C++ symbol file with about 750k unique
>> symbol names, using crc32 based id yields 71 coll
>
> I don't think existing profile data matter.
>
> For perfect fresh profile, using external id has the chance of
> collision. I have tested with a C++ symbol file with about 750k unique
> symbol names, using crc32 based id yields 71 collisions --- the rate
> is ~0.009%.
init_node_map will reso
It's worth noting that merely changing the hash function from crc32 to
something that's 64 bit long is enough to make sure collisions does
not happen. Maybe it's worth the trouble?
On Wed, Jul 23, 2014 at 10:42 AM, Xinliang David Li wrote:
>
> On Tue, Jul 22, 2014 at 8:14 PM, Jeff Law wrote:
> >
yes -- I am thinking about this and other better hash functions.
Changing it to 64bit will cause profile format change and increase in
profile data size.
David
On Wed, Jul 23, 2014 at 10:52 AM, Yi Yang wrote:
> It's worth noting that merely changing the hash function from crc32 to
> something th
On Tue, Jul 22, 2014 at 8:14 PM, Jeff Law wrote:
> On 07/16/14 14:32, Xinliang David Li wrote:
>>
>> Instrumentation based FDO is designed to work when the source files
>> that are used to generate the instr binary match exactly with the
>> sources in profile-use compile. It is known historically
On 07/16/14 14:32, Xinliang David Li wrote:
Instrumentation based FDO is designed to work when the source files
that are used to generate the instr binary match exactly with the
sources in profile-use compile. It is known historically that using
stale profile (due to source changes, not gcda form
Any other concern of the patch? I don't really like the name of the
parameter myself. Do you have better suggestions?
thanks,
David
On Thu, Jul 17, 2014 at 10:17 AM, Xinliang David Li wrote:
>>>
>>> I see why you do not like first_global_object_name because changing it
>>> would cause
>>> all
>>
>> I see why you do not like first_global_object_name because changing it would
>> cause
>> all functions from that unit to drop the profiles. Perhaps we can combine
>> function name
>> and compilation unit (gcov file) name?
>
> that is a good idea -- it will also solve the LTO problem you men
On Wed, Jul 16, 2014 at 4:42 PM, Jan Hubicka wrote:
>> Instrumentation based FDO is designed to work when the source files
>> that are used to generate the instr binary match exactly with the
>> sources in profile-use compile. It is known historically that using
>> stale profile (due to source cha
> Instrumentation based FDO is designed to work when the source files
> that are used to generate the instr binary match exactly with the
> sources in profile-use compile. It is known historically that using
> stale profile (due to source changes, not gcda format change) can lead
> to lots of misma
Instrumentation based FDO is designed to work when the source files
that are used to generate the instr binary match exactly with the
sources in profile-use compile. It is known historically that using
stale profile (due to source changes, not gcda format change) can lead
to lots of mismatch warnin
13 matches
Mail list logo
