Hi Cary,
Is the new patch ok for google-4_9?
Thanks,
Wei.
On Sun, Aug 24, 2014 at 8:53 PM, Wei Mi <w...@google.com> wrote:
> To avoid the unused new discriminator value, I added a map
> "found_call_this_line" to track whether a call is the first call in a
> source line seen when assigning discriminators. For the first call in
> a source line, its discriminator is 0. For the following calls in the
> same source line, a new discriminator will be used everytime. The new
> patch is attached. Internal perf test and regression test are ok. Is
> it ok for google-4_9?
>
> Thanks,
> Wei.
>
>
>
> On Thu, Aug 7, 2014 at 2:10 PM, Wei Mi <w...@google.com> wrote:
>> Yes, that is intentional. It is to avoid assiging a discriminator for
>> the first call in the group of calls with the same source lineno.
>> Starting from the second call in the group, it will get a different
>> discriminator with previous call in the same group.
>>
>> Thanks,
>> Wei.
>>
>> On Thu, Aug 7, 2014 at 12:17 PM, Cary Coutant <ccout...@google.com> wrote:
>>>> static int
>>>> -next_discriminator_for_locus (location_t locus)
>>>> +increase_discriminator_for_locus (location_t locus, bool return_next)
>>>> {
>>>> struct locus_discrim_map item;
>>>> struct locus_discrim_map **slot;
>>>> @@ -934,8 +936,10 @@ next_discriminator_for_locus (location_t
>>>> (*slot)->locus = locus;
>>>> (*slot)->discriminator = 0;
>>>> }
>>>> +
>>>> (*slot)->discriminator++;
>>>> - return (*slot)->discriminator;
>>>> + return return_next ? (*slot)->discriminator
>>>> + : (*slot)->discriminator - 1;
>>>> }
>>>
>>> Won't this have the effect of sometimes incrementing the next
>>> available discriminator without actually using the new value? That is,
>>> if you call it once with return_next == false, and then with
>>> return_next == true.
>>>
>>> -cary
