https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #47 from Linus Torvalds ---
(In reply to Richard Biener from comment #45)
> For user code
>
> volatile long long x;
> void foo () { x++; }
>
> emitting inc + adc with memory operands is only "incorrect" in re-ordering
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #46 from rguenther at suse dot de ---
On Mon, 30 Jan 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
>
> --- Comment #44 from Jakub Jelinek ---
> I guess we should try and see.
> For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #45 from Richard Biener ---
(In reply to Linus Torvalds from comment #43)
> (In reply to Richard Biener from comment #42)
> >
> > I think if we want to avoid doing optimizations on gcov counters we should
> > make them volatile.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #44 from Jakub Jelinek ---
I guess we should try and see.
For volatile,
--- gcc/coverage.cc 2023-01-02 09:32:37.078072992 +0100
+++ gcc/coverage.cc 2023-01-30 09:24:45.219951352 +0100
@@ -774,6 +774,7 @@ build_var (tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #43 from Linus Torvalds ---
(In reply to Richard Biener from comment #42)
>
> I think if we want to avoid doing optimizations on gcov counters we should
> make them volatile.
Honestly, that sounds like the cleanest and safest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #42 from Richard Biener ---
(In reply to Jakub Jelinek from comment #40)
> (In reply to Jan Hubicka from comment #39)
> > I was wonering if we should not provide flag to turn all counts
> > volatile. That way we will still have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #41 from Richard Biener ---
(In reply to Linus Torvalds from comment #31)
> (In reply to Richard Biener from comment #26)
> >
> > Now, in principle we should have applied store-motion and not only PRE which
> > would have avoided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #40 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #39)
> I was wonering if we should not provide flag to turn all counts
> volatile. That way we will still have race conditions on their updates
> (and it would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #39 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
>
> --- Comment #35 from Vladimir Makarov ---
> (In reply to Jakub Jelinek from comment #34)
> > Seems right now DECL_NONALIASED is only used on these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #38 from Tang, Feng ---
Created attachment 54368
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54368=edit
objdump of prep_compound_page() with patch in comment 35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #37 from Tang, Feng ---
Created attachment 54367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54367=edit
page_alloc.i with patch in comment 35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #36 from Tang, Feng ---
(In reply to Vladimir Makarov from comment #35)
> (In reply to Jakub Jelinek from comment #34)
> > Seems right now DECL_NONALIASED is only used on these coverage vars and on
> > Fortran caf tokens, so perhaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #35 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #34)
> Seems right now DECL_NONALIASED is only used on these coverage vars and on
> Fortran caf tokens, so perhaps a quick workaround would be on the LRA side
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #33 from Jakub Jelinek ---
It is the default unless -pthread is specified:
%{fprofile-arcs|fprofile-generate*|coverage:\
%{!fprofile-update=single:\
%{pthread:-fprofile-update=prefer-atomic}}}
So, when one uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #32 from Linus Torvalds ---
Brw, where does the -fprofile-update=single/atomic come from?
The kernel just uses
CFLAGS_GCOV:= -fprofile-arcs -ftest-coverage
for this case. So I guess 'single' is just the default value?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #31 from Linus Torvalds ---
(In reply to Richard Biener from comment #26)
>
> Now, in principle we should have applied store-motion and not only PRE which
> would have avoided the issue, not tricking the RA into reloading the value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #30 from Linus Torvalds ---
(In reply to Richard Biener from comment #26)
> And yes, to IV optimization the gcov counter for the loop body is just
> another IV candidate that can be used, and in this case it allows to elide
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #29 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #27)
> Well, we could in -fprofile-update=single (or perhaps in a new single-like
> mode) mark the gcov artificial vars volatile or with some flag that would at
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #28 from Richard Biener ---
(In reply to Jakub Jelinek from comment #27)
> (In reply to Richard Biener from comment #25)
> > Ah, reading more comments, no - it probably doesn't. Jakub correctly says
> > that there seems to be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #27 from Jakub Jelinek ---
(In reply to Richard Biener from comment #25)
> Ah, reading more comments, no - it probably doesn't. Jakub correctly says
> that there seems to be a data race necessary to trigger this, so it doesn't
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #26 from Richard Biener ---
And yes, to IV optimization the gcov counter for the loop body is just another
IV candidate that can be used, and in this case it allows to elide the
otherwise
unused original IV.
Now, in principle we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #25 from Richard Biener ---
(In reply to Richard Biener from comment #24)
> Does
>
> diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
> index 0dd47910f97..f780c0ce08c 100644
> --- a/gcc/tree-ssa-loop-ivopts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #24 from Richard Biener ---
Does
diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
index 0dd47910f97..f780c0ce08c 100644
--- a/gcc/tree-ssa-loop-ivopts.cc
+++ b/gcc/tree-ssa-loop-ivopts.cc
@@ -2241,7 +2241,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #23 from Jakub Jelinek ---
We could mark the __gcov* artificial vars with some flag (unless they are
already) and try to avoid using IVs loaded from those in IVOPTs, but as can be
seen above, the chosen IV really isn't that memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #22 from Uroš Bizjak ---
BTW: It is the reload pass that duplicates read from
__gcov0.prep_compound_page[7].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #20 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #19)
> __gcov0.prep_compound_page. But as shown in Comment #15, we have two
Comment #16, actually.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #19 from Uroš Bizjak ---
Some further analysis:
pretmp_94 = __gcov0.prep_compound_page[7]; <--
_179 = pretmp_94 + 1; <--
ivtmp.1725_211 = (unsigned long long) _179;
_135 = (unsigned int) nr_pages_11;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
Uroš Bizjak changed:
What|Removed |Added
Component|target |tree-optimization
30 matches
Mail list logo
