> Hi.
>
> So the first part is about support of N tracked values to be supported.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
> From f3e361fb6d799acf538bc76a91bfcc8e265b7cbe Mon Sep 17 00:00:00 2001
> From: Martin Lisk
@Honza: PING^1
On 6/20/19 4:45 PM, Martin Liška wrote:
> Hi.
>
> So the first part is about support of N tracked values to be supported.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
On 2019/6/24 10:34, luoxhu wrote:
Hi Honza,
Thanks very much to get so many useful comments from you.
As a newbie to GCC, not sure whether my questions are described clearly
enough. Thanks for your patience in advance. :)
On 2019/6/20 21:47, Jan Hubicka wrote:
Hi,
some comments on the ipa
Hi Honza,
Thanks very much to get so many useful comments from you.
As a newbie to GCC, not sure whether my questions are described clearly
enough. Thanks for your patience in advance. :)
On 2019/6/20 21:47, Jan Hubicka wrote:
Hi,
some comments on the ipa part of the patch
(and thanks for wor
Hi.
So the first part is about support of N tracked values to be supported.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From f3e361fb6d799acf538bc76a91bfcc8e265b7cbe Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Wed, 19 Jun 2
Hi,
some comments on the ipa part of the patch
(and thanks for working on it - this was on my TODO list for years)
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index de82316d4b1..0d373a67d1b 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -553,6 +553,7 @@ cgraph_node::get_create (tree decl)
On 6/20/19 8:15 AM, luoxhu wrote:
> Hi Martin,
>
> On 2019/6/20 09:59, luoxhu wrote:
>>
>>
>> On 2019/6/19 20:18, Martin Liška wrote:
>>> On 6/19/19 10:56 AM, Martin Liška wrote:
Thank you very much for the numbers. Today, I'm going to prepare the
generalization of single-value counter
Hi Martin,
On 2019/6/20 09:59, luoxhu wrote:
On 2019/6/19 20:18, Martin Liška wrote:
On 6/19/19 10:56 AM, Martin Liška wrote:
Thank you very much for the numbers. Today, I'm going to prepare the
generalization of single-value counter to track N values.
Ok, here's a patch candidate that doe
On 2019/6/19 20:18, Martin Liška wrote:
On 6/19/19 10:56 AM, Martin Liška wrote:
Thank you very much for the numbers. Today, I'm going to prepare the
generalization of single-value counter to track N values.
Ok, here's a patch candidate that does tracking of most common N values. For
your
On 6/19/19 10:56 AM, Martin Liška wrote:
> Thank you very much for the numbers. Today, I'm going to prepare the
> generalization of single-value counter to track N values.
Ok, here's a patch candidate that does tracking of most common N values. For
your test-case I can see:
pr69678.gcda:01a
On 6/19/19 10:50 AM, luoxhu wrote:
> Hi Martin,
>
> On 2019/6/18 18:21, Martin Liška wrote:
>> On 6/18/19 3:45 AM, Xiong Hu Luo wrote:
>>> 6.2. SPEC2017 peakrate:
>>> 523.xalancbmk_r (+4.87%); 538.imagick_r (+4.59%); 511.povray_r
>>> (+13.33%);
>>> 525.x264_r (-5.29%).
>>
Hi Martin,
On 2019/6/18 18:21, Martin Liška wrote:
On 6/18/19 3:45 AM, Xiong Hu Luo wrote:
6.2. SPEC2017 peakrate:
523.xalancbmk_r (+4.87%); 538.imagick_r (+4.59%); 511.povray_r
(+13.33%);
525.x264_r (-5.29%).
Can you please elaborate what are the key indirect call pr
On 6/19/19 7:38 AM, luoxhu wrote:
> Actually, the algorithm of function __gcov_one_value_profiler_body in
> libgcc/libgcov-profiler.c has functionality issue when profiling the testcase
> I provide.
It's designed to track most common value and uses only one slot for storage
place.
As mentioned
Hi Martin,
On 2019/6/18 17:34, Martin Liška wrote:
On 6/18/19 11:02 AM, luoxhu wrote:
Hi,
On 2019/6/18 13:51, Martin Liška wrote:
On 6/18/19 3:45 AM, Xiong Hu Luo wrote:
Hello.
Thank you for the interest in the area.
This patch aims to fix PR69678 caused by PGO indirect call profiling bug
On 6/18/19 3:45 AM, Xiong Hu Luo wrote:
> 6.2. SPEC2017 peakrate:
> 523.xalancbmk_r (+4.87%); 538.imagick_r (+4.59%); 511.povray_r
> (+13.33%);
> 525.x264_r (-5.29%).
Can you please elaborate what are the key indirect call promotions that are
needed
to achieve such a signifi
On 6/18/19 12:07 PM, Segher Boessenkool wrote:
> On Tue, Jun 18, 2019 at 11:34:03AM +0200, Martin Liška wrote:
>> I've got it. So it's situation where you have distribution equal to 50% and
>> 50%. Note that it's
>> the only valid situation where both edges with be >= 50%. That's the
>> threshold
On Tue, Jun 18, 2019 at 11:34:03AM +0200, Martin Liška wrote:
> I've got it. So it's situation where you have distribution equal to 50% and
> 50%. Note that it's
> the only valid situation where both edges with be >= 50%. That's the
> threshold for which
> we speculatively devirtualize edges.
Bu
On 6/18/19 11:02 AM, luoxhu wrote:
> Hi,
>
> On 2019/6/18 13:51, Martin Liška wrote:
>> On 6/18/19 3:45 AM, Xiong Hu Luo wrote:
>>
>> Hello.
>>
>> Thank you for the interest in the area.
>>
>>> This patch aims to fix PR69678 caused by PGO indirect call profiling bugs.
>>> Currently the default ins
Hi,
On 2019/6/18 13:51, Martin Liška wrote:
On 6/18/19 3:45 AM, Xiong Hu Luo wrote:
Hello.
Thank you for the interest in the area.
This patch aims to fix PR69678 caused by PGO indirect call profiling bugs.
Currently the default instrument function can only find the indirect function
that cal
On 6/18/19 3:45 AM, Xiong Hu Luo wrote:
Hello.
Thank you for the interest in the area.
> This patch aims to fix PR69678 caused by PGO indirect call profiling bugs.
> Currently the default instrument function can only find the indirect function
> that called more than 50% with an incorrect count
This patch aims to fix PR69678 caused by PGO indirect call profiling bugs.
Currently the default instrument function can only find the indirect function
that called more than 50% with an incorrect count number returned. This patch
leverages the "--param indir-call-topn-profile=1" and enables multi
21 matches
Mail list logo
