https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #47 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:14162197fd4cf0e3a848d32bd9385876e1b1f249
commit r10-7609-g14162197fd4cf0e3a848d32bd9385876e1b1f249
Author: Jeff Law
Date: Tue Apr 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #46 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:7f26e60c2600f0a676fc9370390ebf0a3c78f31c
commit r10-7548-g7f26e60c2600f0a676fc9370390ebf0a3c78f31c
Author: Jeff Law
Date: Fri Apr 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #45 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:b949f8e2acb49273b2f08ecaa3bc7128baaad850
commit r10-7544-gb949f8e2acb49273b2f08ecaa3bc7128baaad850
Author: Jeff Law
Date: Fri Apr 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #43 from Martin Liška ---
(In reply to Jakub Jelinek from comment #42)
> Is that good enough to mark this PR as resolved? In #c0 you said before
> Richard's change it took ~200s, which is more than 2m21s, though it is
> unclear if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #42 from Jakub Jelinek ---
Is that good enough to mark this PR as resolved? In #c0 you said before
Richard's change it took ~200s, which is more than 2m21s, though it is unclear
if those 141s are with checking compiler or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #41 from Martin Liška ---
The current master does:
$ time gfortran module_configure.fppized.f90 -c -march=znver2 -std=legacy
-fconvert=big-endian -fno-openmp -Ofast -march=znver2 -g
...
real2m21.190s
user2m20.487s
sys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #40 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:86c924113208f58fdda24078c9cc9285ee8000cd
commit r10-7516-g86c924113208f58fdda24078c9cc9285ee8000cd
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #39 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2c0fa3ecf70d199af18785702e9e0548fd3ab793
commit r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #38 from Jakub Jelinek ---
No, far from it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #37 from Martin Liška ---
@Jakub: Can we close it? Or do you plan any other patch for it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #36 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9708ca2be40399d6266bc85c99e085e3fe27a809
commit r10-7392-g9708ca2be40399d6266bc85c99e085e3fe27a809
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #35 from Martin Liška ---
The suggested patch helped to reduce compilation to:
2m54s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #34 from Jakub Jelinek ---
Created attachment 48081
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48081=edit
gcc10-pr92264-wip.patch
Further updated patch, this one passes bootstrap on both x86_64-linux and
i686-linux and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #33 from Jakub Jelinek ---
Created attachment 48075
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48075=edit
gcc10-pr92264-wip.patch
Updated patch, which doesn't ICE anymore, and creates 10500 instead of 12000
VALUEs during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #32 from Jakub Jelinek ---
Some incremental progress, but still ICEs...
--- gcc/cselib.c2020-03-20 17:42:02.333023994 +0100
+++ gcc/cselib.c2020-03-20 19:23:33.506622424 +0100
@@ -58,6 +58,16 @@
static void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #31 from Jakub Jelinek ---
Created attachment 48073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48073=edit
gcc10-pr92264-wip.patch
WIP patch to try special casing cselib handling of stack pointer VALUEs.
The intent is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #30 from Jakub Jelinek ---
Or perhaps just do:
--- gcc/var-tracking.c.jj 2020-01-12 11:54:38.532381439 +0100
+++ gcc/var-tracking.c 2020-03-19 15:49:19.457340470 +0100
@@ -6112,7 +6112,8 @@ add_stores (rtx loc, const_rtx expr,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #29 from Jakub Jelinek ---
So, the reason why the values aren't being marked as sp based is given in
PR54796 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54796#c2
In these functions, there is no fp_setter insn, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #28 from Martin Liška ---
(In reply to Richard Biener from comment #25)
> Created attachment 48064 [details]
> more localized caching
>
> Updated and simplified patch. Maybe it does help depending on how we have
> shared locs for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #27 from Jakub Jelinek ---
So, I've looked at two cases from those where visited_vals.length () > 100
returned non-NULL, in particular Wsizeof-pointer-memaccess1.c and
diagnostic-show-locus.c. In both all the cases where it returned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #26 from Richard Biener ---
(In reply to Martin Liška from comment #24)
> (In reply to Richard Biener from comment #23)
> > (In reply to Richard Biener from comment #22)
> > > Created attachment 48063 [details]
> > > more localized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
Richard Biener changed:
What|Removed |Added
Attachment #48063|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #24 from Martin Liška ---
(In reply to Richard Biener from comment #23)
> (In reply to Richard Biener from comment #22)
> > Created attachment 48063 [details]
> > more localized caching
> >
> > Like this. Martin, can you also check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #23 from Richard Biener ---
(In reply to Richard Biener from comment #22)
> Created attachment 48063 [details]
> more localized caching
>
> Like this. Martin, can you also check the effect on this one?
We can actually simplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #22 from Richard Biener ---
Created attachment 48063
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48063=edit
more localized caching
Like this. Martin, can you also check the effect on this one?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #21 from Richard Biener ---
(In reply to Jakub Jelinek from comment #19)
> I think caching is problematic, for a couple of reasons:
> 1) for non-cselib_preserved_value_p, the loc list is dynamic and keeps
> changing, locs are added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #20 from Martin Liška ---
(In reply to Richard Biener from comment #17)
> Created attachment 48061 [details]
> cache base term
>
> I wonder if we could simply cache the base terms in elt_loc_list? Does that
> make a difference?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #19 from Jakub Jelinek ---
I think caching is problematic, for a couple of reasons:
1) for non-cselib_preserved_value_p, the loc list is dynamic and keeps
changing, locs are added and removed as we go through the basic blocks
2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #18 from Richard Biener ---
Note also that param_max_find_base_term_values limits recursion depth but not
width (the loc list traversals). The original visited_vals thing was to
prevent infinite recursion only. If the global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #17 from Richard Biener ---
Created attachment 48061
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48061=edit
cache base term
I wonder if we could simply cache the base terms in elt_loc_list? Does that
make a difference?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #16 from Martin Liška ---
PR88440 is also slightly related where enablement of
-ftree-loop-distribute-patterns caused longer compilation:
521.wrf_r: 310 -> 346s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #15 from Richard Biener ---
WRF initial_config has very very very many (nested) loops to initialize
globals.
IIRC there's a related bug running into the very same issue when prefetching
is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #14 from Martin Liška ---
For firefox with LTO we get:
$ wc -l /tmp/fbt
1645 /tmp/fbt
$ sort /tmp/fbt | uniq -c | sort -n | tac | head -n20
10 64 /tmp/libxul.so.J1HwqB.ltrans17.o CollectReports 103 0
10 64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #13 from Martin Liška ---
So for the problematic wrf file we get:
$ gfortran module_configure.fppized.f90 -c -march=znver2 -std=legacy
-fconvert=big-endian -fno-openmp -Ofast -march=znver2 -g
...
$ wc -l /tmp/fbt
26273112 /tmp/fbt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #12 from Jakub Jelinek ---
I guess we can consider lowering the default value of the param and/or having
separate param for var-tracking vs. for normal RTL optimizations.
But before doing that I think we want to gather some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #11 from Martin Liška ---
So it finishes in 50m16s.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #10 from Jakub Jelinek ---
(In reply to Martin Liška from comment #9)
> With --param max-find-base-term-values=100 it takes 4m24s.
> With --param max-find-base-term-values=1 it takes 2m22s.
So, if you e.g. bump the timeout to 30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #9 from Martin Liška ---
With --param max-find-base-term-values=100 it takes 4m24s.
With --param max-find-base-term-values=1 it takes 2m22s.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #8 from Martin Liška ---
With --param max-find-base-term-values=10 it takes 2m34s.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #7 from Martin Liška ---
(In reply to Jakub Jelinek from comment #6)
> In r10-7086-g2e94d3ee47be0742df843d95e3d1bf1da11e4796 I've added a param
> controlled cap on the number of VALUEs walked by a single toplevel
> find_base_term.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #4 from Martin Liška ---
> If you have handy access to the reproducer, is it -g that makes
> the difference?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Similar to what Richard says, this sounds like a latent bug. One of
the effects of that rev was to prevent unnecessary invalidation of
equivalences based on the stack pointer and frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #2 from Martin Liška ---
Just for the record, the compilation takes now ~2:30 hours.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
Richard Biener changed:
What|Removed |Added
Target||x86_64-linux-gnu
48 matches
Mail list logo
