On 1/25/21 3:55 PM, Jan Hubicka wrote:
I've just installed the patch.
About the negative total value. Something similar can handle it:
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index df08e882dd7..ddc688509bd 100644
--- a/libgcc/libgcov.h
+++ b/libgcc/libgcov.h
@@ -443,7 +443,13 @@ gcov_to
On 1/25/21 4:06 PM, H.J. Lu wrote:
On Mon, Jan 25, 2021 at 4:54 AM Martin Liška wrote:
On 1/22/21 3:51 PM, Jan Hubicka wrote:
gcc/ChangeLog:
PR gcov-profile/98739
* common.opt: Add missing sign symbol.
* value-prof.c (get_nth_most_common_value): Restore handling
of PR
On Mon, Jan 25, 2021 at 4:54 AM Martin Liška wrote:
>
> On 1/22/21 3:51 PM, Jan Hubicka wrote:
> >> gcc/ChangeLog:
> >>
> >> PR gcov-profile/98739
> >> * common.opt: Add missing sign symbol.
> >> * value-prof.c (get_nth_most_common_value): Restore handling
> >> of PROFILE_REPRO
> On 1/21/21 7:40 PM, Martin Liška wrote:
> > Most of the changes are in known contexts:
>
> I've made some progress here, but still I'm unable to get a reproducible
> build.
> Now I see difference in:
>
>161/ 649: cp/decl.o: different
>180/ 649: cp/parser.o: different
>262/ 64
> I've just installed the patch.
>
> About the negative total value. Something similar can handle it:
> diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
> index df08e882dd7..ddc688509bd 100644
> --- a/libgcc/libgcov.h
> +++ b/libgcc/libgcov.h
> @@ -443,7 +443,13 @@ gcov_topn_add_value (gcov_type *
On 1/22/21 3:51 PM, Jan Hubicka wrote:
gcc/ChangeLog:
PR gcov-profile/98739
* common.opt: Add missing sign symbol.
* value-prof.c (get_nth_most_common_value): Restore handling
of PROFILE_REPRODUCIBILITY_PARALLEL_RUNS and
PROFILE_REPRODUCIBILITY_MULTITHREAD
On 1/21/21 7:40 PM, Martin Liška wrote:
Most of the changes are in known contexts:
I've made some progress here, but still I'm unable to get a reproducible build.
Now I see difference in:
161/ 649: cp/decl.o: different
180/ 649: cp/parser.o: different
262/ 649: generic-match.o:
> gcc/ChangeLog:
>
> PR gcov-profile/98739
> * common.opt: Add missing sign symbol.
> * value-prof.c (get_nth_most_common_value): Restore handling
> of PROFILE_REPRODUCIBILITY_PARALLEL_RUNS and
> PROFILE_REPRODUCIBILITY_MULTITHREADED.
>
> libgcc/ChangeLog:
>
>
> >
> > I would make this go in separately from the feature itself (it is build
> > machinery change).
>
> All right.
>
> > Especially since you say it does not reach
> > reproducibility anyway until we patch hashtables?
>
> Yep, I'm testing a patch that should improve the reproducible build.
>
There's a simpler patch that can restore the behavior.
TOP N counter pruning is elided.
Martin
>From 4b4956acfda45f6102338a27a9c962171ca4094b Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 22 Jan 2021 11:27:16 +0100
Subject: [PATCH] Restore profile reproducibility.
gcc/ChangeLog:
PR g
On 1/22/21 2:51 PM, Jan Hubicka wrote:
diff --git a/Makefile.in b/Makefile.in
index 247cb9c8711..03785200dc7 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -565,7 +565,7 @@ STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
STAGEtrain_CFLAGS = $(filter-out -fchecking=1,$(STAGE3_CFLAGS))
STAGEtrain_TFLAGS
>
> I remember we had issues with streaming running in parallel with
> threads. Can't we get here corruption without atomic updates of nndoes
> and the next pointer?
>
> I also remember that these parlalel updates was pretty bad, because if
> you have multithreaded concurent update of very frequ
> diff --git a/Makefile.in b/Makefile.in
> index 247cb9c8711..03785200dc7 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -565,7 +565,7 @@ STAGEprofile_TFLAGS = $(STAGE2_TFLAGS)
> STAGEtrain_CFLAGS = $(filter-out -fchecking=1,$(STAGE3_CFLAGS))
> STAGEtrain_TFLAGS = $(filter-out -fchecking=1,$
On 1/22/21 2:07 PM, Jan Hubicka wrote:
This is OK. To save future debugging, perhaps I would keep the code
printing the tp first run value to dump file and do
fprintf (dump_file, "Read tp_first_run: %d; ignored because profile
reproducibility is multithreaded\n", node->tp_first_r
> On 1/21/21 8:13 PM, Martin Liška wrote:
> > Yes, it will be a better place!
> >
> > Martin
>
> There's an updated version of the patch.
>
> Thoughts?
> Thanks,
> Martin
> From 0be300d1d69e98624f7be5b54931126965f1436e Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Fri, 22 Jan 2021 14:0
On 1/21/21 8:13 PM, Martin Liška wrote:
Yes, it will be a better place!
Martin
There's an updated version of the patch.
Thoughts?
Thanks,
Martin
>From 0be300d1d69e98624f7be5b54931126965f1436e Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 22 Jan 2021 14:00:30 +0100
Subject: [PATCH] D
On 1/21/21 8:16 PM, Jan Hubicka wrote:
On 1/21/21 8:03 PM, Jan Hubicka wrote:
What exactly is suggested?
This one.
Martin
From 22bbf5342f2b73fad6c0286541bba6699c617380 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 21 Jan 2021 09:02:31 +0100
Subject: [PATCH 1/2] Restore -fprofile
> On 1/21/21 2:46 PM, Jan Hubicka wrote:
> > I think easy way to get users of this option is to make profile not
> > reproducible by default and modify packages to use right reproducibility
> > option when reproducible builds are intended. It is not feature that
> > comes for free and I think most
> On 1/21/21 8:03 PM, Jan Hubicka wrote:
> > What exactly is suggested?
>
> This one.
>
> Martin
> From 22bbf5342f2b73fad6c0286541bba6699c617380 Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Thu, 21 Jan 2021 09:02:31 +0100
> Subject: [PATCH 1/2] Restore -fprofile-reproducibility flag.
>
On 1/21/21 8:02 PM, Jan Hubicka wrote:
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index b401f0817a3..042c03d819e 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1961,8 +1961,9 @@ expand_all_functions (void)
}
/* First output functions with time profile in specified o
On 1/21/21 8:03 PM, Jan Hubicka wrote:
What exactly is suggested?
This one.
Martin
>From 22bbf5342f2b73fad6c0286541bba6699c617380 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 21 Jan 2021 09:02:31 +0100
Subject: [PATCH 1/2] Restore -fprofile-reproducibility flag.
gcc/ChangeLog:
PR
> > This will become more common problem for multithreaded profiles where
> > one needs to annotate locking and busy waiting loops in them for example
> > (or the scheduler responsible for executing paralle tasks).
> >
> > I can see this to be practically achievable but we probably want to
> > pro
> diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
> index b401f0817a3..042c03d819e 100644
> --- a/gcc/cgraphunit.c
> +++ b/gcc/cgraphunit.c
> @@ -1961,8 +1961,9 @@ expand_all_functions (void)
>}
>
>/* First output functions with time profile in specified order. */
> - qsort (tp_fir
> On 1/21/21 7:45 PM, Jan Hubicka wrote:
> > For this reason we merge by computing average, which is stable over
> > reordering the indices
>
> Looking at the implementation, we merge by using minimum value:
>
> /* Time profiles are merged so that minimum from all valid (greater than zero)
>
On 1/21/21 7:45 PM, Jan Hubicka wrote:
For this reason we merge by computing average, which is stable over
reordering the indices
Looking at the implementation, we merge by using minimum value:
/* Time profiles are merged so that minimum from all valid (greater than zero)
is stored. The
> On 1/21/21 3:01 PM, Jan Hubicka wrote:
> > >
> > > Plus I'm planning to send one more patch that will ignore time profile
> > > when -fprofile-reproduce != serial.
> >
> > Why you need to disable time profiling?
>
> Because you can have 2 training runs (running in parallel) when order is:
> r
On 1/21/21 2:46 PM, Jan Hubicka wrote:
I think easy way to get users of this option is to make profile not
reproducible by default and modify packages to use right reproducibility
option when reproducible builds are intended. It is not feature that
comes for free and I think most users of PGO do
On 1/21/21 3:01 PM, Jan Hubicka wrote:
Plus I'm planning to send one more patch that will ignore time profile when
-fprofile-reproduce != serial.
Why you need to disable time profiling?
Because you can have 2 training runs (running in parallel) when order is:
runA: foo -> bar
runB: bar -> f
>
> Plus I'm planning to send one more patch that will ignore time profile when
> -fprofile-reproduce != serial.
Why you need to disable time profiling?
Honza
> On 1/21/21 9:25 AM, Richard Biener wrote:
> > On Wed, Jan 20, 2021 at 5:25 PM Martin Liška wrote:
> > >
> > > On 1/20/21 5:00 PM, Jan Hubicka wrote:
> > > > There are two thinks that I would like to discuss first
> > > >1) I think the option is stil used for value profiling of divisors
> >
On 1/21/21 9:25 AM, Richard Biener wrote:
On Wed, Jan 20, 2021 at 5:25 PM Martin Liška wrote:
On 1/20/21 5:00 PM, Jan Hubicka wrote:
There are two thinks that I would like to discuss first
1) I think the option is stil used for value profiling of divisors
It's not. Right now the only usa
after testing?
Thanks,
Martin
Honza
I'm sending updated version of the patch.
Martin
From ffbd2fe90dd3bfceecfeefb679572ca2f6b5f333 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 19 Jan 2021 15:43:31 +0100
Subject: [PATCH] Drop profile reproducibility flag as it is not used.
On Wed, Jan 20, 2021 at 5:25 PM Martin Liška wrote:
>
> On 1/20/21 5:00 PM, Jan Hubicka wrote:
> > There are two thinks that I would like to discuss first
> > 1) I think the option is stil used for value profiling of divisors
>
> It's not. Right now the only usage lives in get_nth_most_common_va
00:00:00 2001
> From: Martin Liska
> Date: Tue, 19 Jan 2021 15:43:31 +0100
> Subject: [PATCH] Drop profile reproducibility flag as it is not used.
>
> gcc/ChangeLog:
>
> PR gcov-profile/98739
> * common.opt: Drop -fprofile-reproducibility flag.
>
gcda files
I'm sending updated version of the patch.
Martin
>From ffbd2fe90dd3bfceecfeefb679572ca2f6b5f333 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 19 Jan 2021 15:43:31 +0100
Subject: [PATCH] Drop profile reproducibility flag as it is not used.
gcc/ChangeLog:
PR gcov-prof
On 1/20/21 2:11 PM, Richard Biener wrote:
The option was present on the GCC 10 branch as well so I fear we can't
simply remove it. So can you leave it as the usual Ignore entry in common.opt?
Sure.
Otherwise OK, but I guess the issue can still pop up so I'm not sure whether
this is the corr
> On Wed, Jan 20, 2021 at 12:04 PM Martin Liška wrote:
> >
> > Hello.
> >
> > For GCC 11 I've made a change in a way how we track TOP N counters:
> > - dynamic allocation is used for key value pairs
> > - up to 32 values are tracked in parallel
> > - the counters are allocated dynamically and don'
On Wed, Jan 20, 2021 at 12:04 PM Martin Liška wrote:
>
> Hello.
>
> For GCC 11 I've made a change in a way how we track TOP N counters:
> - dynamic allocation is used for key value pairs
> - up to 32 values are tracked in parallel
> - the counters are allocated dynamically and don't occupy so much
Hello.
For GCC 11 I've made a change in a way how we track TOP N counters:
- dynamic allocation is used for key value pairs
- up to 32 values are tracked in parallel
- the counters are allocated dynamically and don't occupy so much space
in BSS executable
Having that we can track more values a
39 matches
Mail list logo
