* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
@ 2020-03-10 8:09 ` jakub at gcc dot gnu.org
2020-03-17 9:21 ` marxin at gcc dot gnu.org
` (40 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-10 8:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In r10-7086-g2e94d3ee47be0742df843d95e3d1bf1da11e4796 I've added a param
controlled cap on the number of VALUEs walked by a single toplevel
find_base_term.
Does it make a difference on this?
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
2020-03-10 8:09 ` [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318 jakub at gcc dot gnu.org
@ 2020-03-17 9:21 ` marxin at gcc dot gnu.org
2020-03-17 9:25 ` marxin at gcc dot gnu.org
` (39 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-17 9:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
(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.
> Does it make a difference on this?
The current master still fails with a timeout of 5 minutes. Perf looks a bit
lower for find_base_term:
46.64% f951 f951 [.] find_base_term
8.91% f951 f951 [.] ix86_find_base_term
2.19% f951 libc-2.31.so [.] _int_malloc
2.15% f951 f951 [.] get_ref_base_and_extent
2.11% f951 f951 [.] bitmap_set_bit
2.03% f951 f951 [.] find_base_term
1.75% f951 f951 [.] cselib_sp_based_value_p
1.52% f951 f951 [.] pre_expr_reaches_here_p_work
1.51% f951 f951 [.] fsm_find_thread_path
1.20% f951 f951 [.] build_object_conflicts
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
2020-03-10 8:09 ` [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318 jakub at gcc dot gnu.org
2020-03-17 9:21 ` marxin at gcc dot gnu.org
@ 2020-03-17 9:25 ` marxin at gcc dot gnu.org
2020-03-17 9:46 ` marxin at gcc dot gnu.org
` (38 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-17 9:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
With --param max-find-base-term-values=10 it takes 2m34s.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-03-17 9:25 ` marxin at gcc dot gnu.org
@ 2020-03-17 9:46 ` marxin at gcc dot gnu.org
2020-03-17 9:57 ` jakub at gcc dot gnu.org
` (37 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-17 9:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
With --param max-find-base-term-values=100 it takes 4m24s.
With --param max-find-base-term-values=1 it takes 2m22s.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-03-17 9:46 ` marxin at gcc dot gnu.org
@ 2020-03-17 9:57 ` jakub at gcc dot gnu.org
2020-03-17 11:37 ` marxin at gcc dot gnu.org
` (36 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-17 9:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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 minutes, does it complete even with the
default setting and how long does it take?
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2020-03-17 9:57 ` jakub at gcc dot gnu.org
@ 2020-03-17 11:37 ` marxin at gcc dot gnu.org
2020-03-18 13:25 ` jakub at gcc dot gnu.org
` (35 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-17 11:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
So it finishes in 50m16s.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2020-03-17 11:37 ` marxin at gcc dot gnu.org
@ 2020-03-18 13:25 ` jakub at gcc dot gnu.org
2020-03-18 16:56 ` marxin at gcc dot gnu.org
` (34 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-18 13:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 statistics to help us
decide on which value we want, like:
--- gcc/alias.c 2020-03-09 13:38:04.534284063 +0100
+++ gcc/alias.c 2020-03-18 14:20:03.669278109 +0100
@@ -2116,6 +2116,14 @@ find_base_term (rtx x)
rtx res = find_base_term (x, visited_vals);
for (unsigned i = 0; i < visited_vals.length (); ++i)
visited_vals[i].first->locs = visited_vals[i].second;
+ if (visited_vals.length () > 100)
+ {
+ FILE *f = fopen ("/tmp/fbt", "a");
+ fprintf (f, "%d %s %s %d %d\n", (int) BITS_PER_WORD,
+ main_input_filename ? main_input_filename : "-",
+ current_function_name (), visited_vals.length (), res !=
NULL_RTX);
+ fclose (f);
+ }
return res;
}
and use it on both x86_64-linux and i686-linux bootstrap/regtest (perhaps other
targets too) and perhaps on some other packages too (firefox, libreoffice,
...).
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2020-03-18 13:25 ` jakub at gcc dot gnu.org
@ 2020-03-18 16:56 ` marxin at gcc dot gnu.org
2020-03-18 20:20 ` marxin at gcc dot gnu.org
` (33 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-18 16:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #13 from Martin Liška <marxin at gcc dot gnu.org> ---
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
$ sort /tmp/fbt | uniq -c | sort -n | tac | head -n10
24666359 64 module_configure.fppized.f90 initial_config 2001 0
482996 64 module_configure.fppized.f90 initial_config 757 0
336377 64 module_configure.fppized.f90 initial_config 620 0
321717 64 module_configure.fppized.f90 initial_config 607 0
288735 64 module_configure.fppized.f90 initial_config 571 0
101785 64 module_configure.fppized.f90 initial_config 317 0
23376 64 module_configure.fppized.f90 initial_config 127 0
22014 64 module_configure.fppized.f90 initial_config 120 0
18135 64 module_configure.fppized.f90 initial_config 107 0
41 64 module_configure.fppized.f90 initial_config 115 0
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2020-03-18 16:56 ` marxin at gcc dot gnu.org
@ 2020-03-18 20:20 ` marxin at gcc dot gnu.org
2020-03-19 7:48 ` rguenth at gcc dot gnu.org
` (32 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-18 20:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
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 /tmp/libxul.so.J1HwqB.ltrans17.o CollectReports 101 0
6 64 /tmp/libxul.so.J1HwqB.ltrans17.o CollectReports 106 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 997 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 996 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 995 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 994 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 993 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 992 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 991 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 988 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 987 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 986 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 985 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 984 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 983 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 982 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 979 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 978 0
2 64 /tmp/libxul.so.J1HwqB.ltrans55.o GetFormat 977 0
there are no bigger values than 1000.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2020-03-18 20:20 ` marxin at gcc dot gnu.org
@ 2020-03-19 7:48 ` rguenth at gcc dot gnu.org
2020-03-19 7:53 ` marxin at gcc dot gnu.org
` (31 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-19 7:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2020-03-19 7:48 ` rguenth at gcc dot gnu.org
@ 2020-03-19 7:53 ` marxin at gcc dot gnu.org
2020-03-19 8:00 ` rguenth at gcc dot gnu.org
` (30 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-19 7:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
PR88440 is also slightly related where enablement of
-ftree-loop-distribute-patterns caused longer compilation:
521.wrf_r: 310 -> 346s
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2020-03-19 7:53 ` marxin at gcc dot gnu.org
@ 2020-03-19 8:00 ` rguenth at gcc dot gnu.org
2020-03-19 8:06 ` rguenth at gcc dot gnu.org
` (29 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-19 8:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 48061
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48061&action=edit
cache base term
I wonder if we could simply cache the base terms in elt_loc_list? Does that
make a difference?
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2020-03-19 8:00 ` rguenth at gcc dot gnu.org
@ 2020-03-19 8:06 ` rguenth at gcc dot gnu.org
2020-03-19 8:27 ` jakub at gcc dot gnu.org
` (28 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-19 8:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
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 caching works a safer approach
would be to turn that visited_vals things into a local cache and see if that's
enough as well.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2020-03-19 8:06 ` rguenth at gcc dot gnu.org
@ 2020-03-19 8:27 ` jakub at gcc dot gnu.org
2020-03-19 8:43 ` marxin at gcc dot gnu.org
` (27 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-19 8:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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) because of the recursion prevention, doesn't it matter from exactly what
VALUE we start walking (in case we have a cycle or cycles)?
3) plus the new param on visited_vals, if we reach it, caching is unreliable
I've performed {x86_64,i686}-linux bootstraps+regtests overnight with the above
mentioned statistics gathering and the end result is 5530878 cases where
find_base_term had visited_vals.length () > 100 on return, but only 1296 cases
out of that where with visited_vals.length () > 100 we actually returned
non-NULL, and no cases of visited_vals.length () > 500 where we returned
non-NULL.
I'm listing just the cases where it returned non-NULL, as can be seen, all are
for -m32 and guess it would be nice to have a look at them what we actually
manage to return and how the VALUE chains look like.
$ grep -v '0$' fbt | sort | uniq -c | sort -r -k +5 -n
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 484 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 482 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 481 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 480 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 479 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 477 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 476 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 473 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 472 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 469 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 468 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 467 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 464 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 463 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 462 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 458 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 456 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 455 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 454 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 453 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 451 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 450 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 447 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 446 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 443 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 442 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 439 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 438 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 437 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 433 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 431 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 430 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 429 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 428 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 426 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 425 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 422 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 421 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 418 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 417 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 414 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 413 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 412 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 410 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 409 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 406 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 405 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 402 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 401 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 398 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 397 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 392 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 390 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 389 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 388 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 387 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 385 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 384 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 381 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 380 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 377 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 376 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 375 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 373 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 372 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 369 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 368 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 367 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 365 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 364 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 361 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 360 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 357 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 356 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 351 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 349 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 348 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 347 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 346 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 344 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 343 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 340 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 339 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 338 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 337 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 335 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 334 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 333 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 332 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 331 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 330 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 327 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 326 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 323 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 322 1
1 32 ../../gcc/range-op.cc selftest::range_tests 318 1
1 32 ../../gcc/range-op.cc selftest::range_tests 317 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 317 1
6 32 ../../gcc/range-op.cc selftest::range_tests 316 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 315 1
1 32 ../../gcc/range-op.cc selftest::range_tests 314 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 314 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 313 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 313 1
1 32 ../../gcc/range-op.cc selftest::range_tests 313 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 312 1
1 32 ../../gcc/range-op.cc selftest::range_tests 312 1
1 32 ../../gcc/et-forest.c selftest::test_simple_tree 312 1
1 32 ../../gcc/range-op.cc selftest::range_tests 310 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 310 1
1 32 ../../gcc/range-op.cc selftest::range_tests 309 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 309 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 308 1
1 32 ../../gcc/et-forest.c selftest::test_simple_tree 307 1
1 32 ../../gcc/range-op.cc selftest::range_tests 306 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 306 1
1 32 ../../gcc/range-op.cc selftest::range_tests 305 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 303 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 303 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 302 1
1 32 ../../gcc/range-op.cc selftest::range_tests 302 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 302 1
2 32 ../../gcc/range-op.cc selftest::range_tests 301 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 301 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 299 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 299 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 298 1
1 32 ../../gcc/range-op.cc selftest::range_tests 298 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 298 1
9 32 ../../gcc/range-op.cc selftest::range_tests 296 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 295 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 295 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 294 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 294 1
1 32 ../../gcc/range-op.cc selftest::range_tests 293 1
1 32 ../../gcc/range-op.cc selftest::range_tests 292 1
5 32 ../../gcc/et-forest.c selftest::test_simple_tree 291 1
1 32 ../../gcc/range-op.cc selftest::range_tests 291 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 291 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 290 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 290 1
1 32 ../../gcc/range-op.cc selftest::range_tests 289 1
1 32 ../../gcc/range-op.cc selftest::range_tests 288 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 287 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 286 1
1 32 ../../gcc/range-op.cc selftest::range_tests 285 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 285 1
1 32 ../../gcc/range-op.cc selftest::range_tests 284 1
5 32 ../../gcc/et-forest.c selftest::test_simple_tree 283 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 283 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 282 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 282 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 281 1
1 32 ../../gcc/range-op.cc selftest::range_tests 281 1
3 32 ../../gcc/range-op.cc selftest::range_tests 280 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 280 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 279 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 278 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 278 1
1 32 ../../gcc/range-op.cc selftest::range_tests 277 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 277 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 275 1
2 32 ../../gcc/range-op.cc selftest::range_tests 275 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 274 1
1 32 ../../gcc/range-op.cc selftest::range_tests 272 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 272 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 271 1
3 32 ../../gcc/range-op.cc selftest::range_tests 271 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 271 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 270 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 270 1
1 32 ../../gcc/range-op.cc selftest::range_tests 268 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 268 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 267 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 267 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 266 1
1 32 ../../gcc/range-op.cc selftest::range_tests 264 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 264 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 263 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 263 1
1 32 ../../gcc/range-op.cc selftest::range_tests 263 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 262 1
2 32 ../../gcc/range-op.cc selftest::range_tests 262 1
1 32 ../../gcc/range-op.cc selftest::range_tests 260 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 260 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 259 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 259 1
1 32 ../../gcc/range-op.cc selftest::range_tests 259 1
6 32 ../../gcc/range-op.cc selftest::range_tests 258 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 258 1
1 32 ../../gcc/range-op.cc selftest::range_tests 256 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 255 1
2 32 ../../gcc/range-op.cc selftest::range_tests 255 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 254 1
1 32 ../../gcc/range-op.cc selftest::range_tests 254 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 254 1
1 32 ../../gcc/range-op.cc selftest::range_tests 252 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 252 1
5 32 ../../gcc/et-forest.c selftest::test_simple_tree 251 1
1 32 ../../gcc/range-op.cc selftest::range_tests 251 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 251 1
6 32 ../../gcc/range-op.cc selftest::range_tests 250 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 250 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 250 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 249 1
1 32 ../../gcc/range-op.cc selftest::range_tests 248 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 247 1
1 32 ../../gcc/range-op.cc selftest::range_tests 247 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 247 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 246 1
1 32 ../../gcc/range-op.cc selftest::range_tests 246 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 246 1
1 32 ../../gcc/range-op.cc selftest::range_tests 244 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 243 1
1 32 ../../gcc/range-op.cc selftest::range_tests 243 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 243 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 242 1
1 32 ../../gcc/range-op.cc selftest::range_tests 240 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 240 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 239 1
1 32 ../../gcc/range-op.cc selftest::range_tests 239 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 239 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 238 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 238 1
1 32 ../../gcc/range-op.cc selftest::range_tests 236 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 236 1
5 32 ../../gcc/et-forest.c selftest::test_simple_tree 235 1
2 32 ../../gcc/range-op.cc selftest::range_tests 235 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 235 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 234 1
1 32 ../../gcc/range-op.cc selftest::range_tests 232 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 232 1
6 32 ../../gcc/range-op.cc selftest::range_tests 231 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 231 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 231 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 230 1
1 32 ../../gcc/range-op.cc selftest::range_tests 228 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 228 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 227 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 227 1
1 32 ../../gcc/range-op.cc selftest::range_tests 227 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 226 1
2 32 ../../gcc/range-op.cc selftest::range_tests 226 1
1 32 ../../gcc/range-op.cc selftest::range_tests 224 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 223 1
1 32 ../../gcc/range-op.cc selftest::range_tests 223 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 222 1
1 32 ../../gcc/range-op.cc selftest::range_tests 222 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 222 1
6 32 ../../gcc/range-op.cc selftest::range_tests 220 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 220 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 219 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 219 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 218 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 218 1
1 32 ../../gcc/range-op.cc selftest::range_tests 218 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 217 1
1 32 ../../gcc/range-op.cc selftest::range_tests 217 1
2 32 ../../gcc/range-op.cc selftest::range_tests 216 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 215 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 215 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 214 1
1 32 ../../gcc/range-op.cc selftest::range_tests 214 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 214 1
1 32 ../../gcc/range-op.cc selftest::range_tests 213 1
1 32 ../../gcc/range-op.cc selftest::range_tests 212 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 211 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 211 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 210 1
1 32 ../../gcc/range-op.cc selftest::range_tests 210 1
1 32 ../../gcc/range-op.cc selftest::range_tests 209 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 208 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 207 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 207 1
8 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 206 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 206 1
1 32 ../../gcc/range-op.cc selftest::range_tests 206 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 206 1
2 32 ../../gcc/range-op.cc selftest::range_tests 205 1
10 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 205 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 204 1
5 32 ../../gcc/et-forest.c selftest::test_simple_tree 203 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 203 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 202 1
1 32 ../../gcc/range-op.cc selftest::range_tests 202 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 199 1
1 32 ../../gcc/range-op.cc selftest::range_tests 199 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 198 1
1 32 ../../gcc/range-op.cc selftest::range_tests 198 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 198 1
2 32 ../../gcc/range-op.cc selftest::range_tests 197 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 196 1
5 32 ../../gcc/et-forest.c selftest::test_simple_tree 195 1
16 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 195 1
1 32 ../../gcc/range-op.cc selftest::range_tests 195 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 195 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 194 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 194 1
18 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 194 1
1 32 ../../gcc/range-op.cc selftest::range_tests 194 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 193 1
1 32 ../../gcc/range-op.cc selftest::range_tests 193 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 191 1
1 32 ../../gcc/range-op.cc selftest::range_tests 191 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 191 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 190 1
1 32 ../../gcc/range-op.cc selftest::range_tests 190 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 190 1
6 32 ../../gcc/range-op.cc selftest::range_tests 187 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 187 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 187 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 186 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 186 1
1 32 ../../gcc/range-op.cc selftest::range_tests 185 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 185 1
8 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 184 1
1 32 ../../gcc/range-op.cc selftest::range_tests 184 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 183 1
1 32 ../../gcc/range-op.cc selftest::range_tests 183 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 183 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 182 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 182 1
1 32 ../../gcc/range-op.cc selftest::range_tests 181 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 181 1
1 32 ../../gcc/range-op.cc selftest::range_tests 180 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 179 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 178 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 178 1
1 32 ../../gcc/range-op.cc selftest::range_tests 177 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 177 1
2 32 ../../gcc/range-op.cc selftest::range_tests 176 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 176 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 175 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 175 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 174 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 174 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 173 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 173 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 173 1
1 32 ../../gcc/range-op.cc selftest::range_tests 173 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 173 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 172 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 172 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 172 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 172 1
12 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 172 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 171 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 171 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 171 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 171 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 170 1
1 32 ../../gcc/range-op.cc selftest::range_tests 170 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 170 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 169 1
1 32 ../../gcc/range-op.cc selftest::range_tests 169 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 168 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 168 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 168 1
1 32 ../../gcc/range-op.cc selftest::range_tests 168 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 167 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 167 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 167 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 167 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 166 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 166 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 166 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 166 1
1 32 ../../gcc/range-op.cc selftest::range_tests 166 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 166 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 165 1
1 32 ../../gcc/range-op.cc selftest::range_tests 165 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 163 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 163 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 163 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 163 1
6 32 ../../gcc/range-op.cc selftest::range_tests 162 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 162 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 162 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 162 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 162 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 162 1
4 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 161 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 161 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 161 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 161 1
10 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 161 1
1 32 ../../gcc/range-op.cc selftest::range_tests 160 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 159 1
1 32 ../../gcc/range-op.cc selftest::range_tests 159 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 158 1
2 32 ../../gcc/range-op.cc selftest::range_tests 158 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 158 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 158 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 158 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 158 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 157 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 157 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 157 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 157 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 156 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 156 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 156 1
1 32 ../../gcc/range-op.cc selftest::range_tests 156 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 156 1
4 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 155 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 155 1
1 32 ../../gcc/range-op.cc selftest::range_tests 155 1
6 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 154 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 154 1
1 32 ../../gcc/range-op.cc selftest::range_tests 154 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 154 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 153 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 153 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 153 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 153 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 152 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 152 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 152 1
1 32 ../../gcc/range-op.cc selftest::range_tests 152 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 151 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 151 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 151 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 151 1
1 32 ../../gcc/range-op.cc selftest::range_tests 151 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 150 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 150 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 149 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 148 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 148 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 148 1
1 32 ../../gcc/range-op.cc selftest::range_tests 148 1
5 32 ../../gcc/range-op.cc selftest::range_tests 147 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 147 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 147 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 147 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 147 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 147 1
2 32 ../../gcc/input.c selftest::test_cpp_utf8 146 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 146 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 146 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 146 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 146 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 146 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 145 1
24 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 144 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 143 1
22 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 143 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 143 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 143 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 143 1
1 32 ../../gcc/range-op.cc selftest::range_tests 143 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 143 1
2 32 ../../gcc/range-op.cc selftest::range_tests 142 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 142 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 142 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 142 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 142 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 142 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 142 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 141 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 141 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 141 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 141 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 139 1
1 32 ../../gcc/range-op.cc selftest::range_tests 139 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 139 1
2 32 ../../gcc/input.c selftest::test_cpp_utf8 138 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 138 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 138 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 138 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 138 1
1 32 ../../gcc/range-op.cc selftest::range_tests 138 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 138 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 137 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 137 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 137 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 137 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 136 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 136 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 136 1
1 32 ../../gcc/range-op.cc selftest::range_tests 136 1
5 32 ../../gcc/range-op.cc selftest::range_tests 135 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 135 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 135 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 134 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 134 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 134 1
24 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 133 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 133 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 133 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 133 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 133 1
22 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 132 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 132 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 132 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 132 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 131 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 131 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 131 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 131 1
1 32 ../../gcc/range-op.cc selftest::range_tests 131 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 131 1
2 32 ../../gcc/input.c selftest::test_cpp_utf8 130 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 130 1
1 32 ../../gcc/range-op.cc selftest::range_tests 130 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 130 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 129 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 128 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 128 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 128 1
1 32 ../../gcc/range-op.cc selftest::range_tests 128 1
5 32 ../../gcc/range-op.cc selftest::range_tests 127 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 127 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 127 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 127 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 127 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 127 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 126 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 126 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 126 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 126 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 126 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 124 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 123 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 123 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 123 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 123 1
1 32 ../../gcc/range-op.cc selftest::range_tests 123 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 123 1
24 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 122 1
2 32 ../../gcc/input.c selftest::test_cpp_utf8 122 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 122 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 122 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 122 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 122 1
1 32 ../../gcc/range-op.cc selftest::range_tests 122 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 122 1
22 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 121 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 121 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 121 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 121 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 121 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 120 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 119 1
3 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 119 1
1 32 ../../gcc/range-op.cc selftest::range_tests 119 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 119 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 118 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 118 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 118 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 118 1
1 32 ../../gcc/range-op.cc selftest::range_tests 118 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 118 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 118 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 117 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 117 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 117 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 116 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 116 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 116 1
1 32 ../../gcc/range-op.cc selftest::range_tests 116 1
5 32 ../../gcc/range-op.cc selftest::range_tests 115 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 115 1
1 32 ../../gcc/tree-cfg.c selftest::test_diamond 115 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 115 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 115 1
2 32 ../../gcc/input.c selftest::test_cpp_utf8 114 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 114 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 114 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 113 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 113 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 113 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 113 1
5 32 ../../gcc/tree-cfg.c selftest::test_diamond 112 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 112 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 112 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 112 1
4 32 ../../gcc/tree-cfg.c selftest::test_diamond 111 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 111 1
20 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 111 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 111 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 111 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 111 1
1 32 ../../gcc/range-op.cc selftest::range_tests 111 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 111 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 111 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 110 1
22 32 ../../../../libgomp/testsuite/libgomp.c/target-teams-1.c foo 110 1
1 32 ../../gcc/range-op.cc selftest::range_tests 110 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 110 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 110 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 108 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 108 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 108 1
1 32 ../../gcc/range-op.cc selftest::range_tests 108 1
5 32 ../../gcc/range-op.cc selftest::range_tests 107 1
4 32 ../../gcc/et-forest.c selftest::test_simple_tree 107 1
2 32 ../../gcc/tree-cfg.c selftest::test_diamond 107 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 107 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 107 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 107 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 107 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 107 1
2 32 ../../gcc/input.c selftest::test_cpp_utf8 106 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 106 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 106 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 106 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 106 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 106 1
1 32 ../../gcc/tree-cfg.c selftest::test_diamond 105 1
3 32 ../../gcc/et-forest.c selftest::test_simple_tree 103 1
2 32
/home/jakub/src/gcc/gcc/testsuite/gfortran.dg/coarray_alloc_comp_2.f08 MAIN__
103 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 103 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 103 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 103 1
1 32 ../../gcc/range-op.cc selftest::range_tests 103 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 103 1
1 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 103 1
3 32 ../../gcc/tree-cfg.c selftest::test_diamond 102 1
2 32 ../../gcc/et-forest.c selftest::test_simple_tree 102 1
2 32 ../../gcc/diagnostic-show-locus.c
selftest::test_diagnostic_show_locus_one_liner_utf8 102 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gfortran.dg/coarray_alloc_comp_2.f08 MAIN__
102 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 102 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 102 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 102 1
1 32 ../../gcc/range-op.cc selftest::range_tests 102 1
1 32 ../../gcc/input.c selftest::test_cpp_utf8 102 1
2 32 ../../gcc/tree-cfg.c selftest::test_diamond 101 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess2.C
f3<0> 101 1
1 32
/home/jakub/src/gcc/gcc/testsuite/g++.dg/torture/Wsizeof-pointer-memaccess1.C
f3 101 1
1 32
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/Wsizeof-pointer-memaccess1.c
f3 101 1
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2020-03-19 8:27 ` jakub at gcc dot gnu.org
@ 2020-03-19 8:43 ` marxin at gcc dot gnu.org
2020-03-19 10:38 ` rguenth at gcc dot gnu.org
` (26 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-19 8:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #20 from Martin Liška <marxin at gcc dot gnu.org> ---
(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?
Yes:
$ time gfortran module_configure.fppized.f90 -c -march=znver2 -std=legacy
-fconvert=big-endian -fno-openmp -Ofast -march=znver2 -g
real 1m43.067s
user 1m42.410s
$ perf report --stdio | head -n20
...
6.26% f951 f951 [.] get_ref_base_and_extent
5.85% f951 f951 [.] bitmap_set_bit
5.72% f951 f951 [.] find_base_term
3.73% f951 f951 [.]
pre_expr_reaches_here_p_work
2.77% f951 f951 [.] fsm_find_thread_path
2.62% f951 f951 [.] rtx_equal_for_memref_p
2.32% f951 f951 [.] build_object_conflicts
2.17% f951 f951 [.] memrefs_conflict_p
1.88% f951 f951 [.] ira_build_conflicts
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2020-03-19 8:43 ` marxin at gcc dot gnu.org
@ 2020-03-19 10:38 ` rguenth at gcc dot gnu.org
2020-03-19 10:38 ` rguenth at gcc dot gnu.org
` (25 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-19 10:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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 and removed as we go through the basic blocks
Sure, but if you look at my patch I'm caching on individual locs, not on
the whole list. That then still doesn't avoid traversing the whole list
if we don't find a base but we'd at least elide further recursion.
The base we pick also depends on the ordering of the list currently
if there ever are two possible choices.
> 2) because of the recursion prevention, doesn't it matter from exactly what
> VALUE we start walking (in case we have a cycle or cycles)?
I think the outcome is essentially random anyways since we pick the first
base we find. I'm quite sure that if we collected "all" bases we'd find
they are not equivalent in some cases.
> 3) plus the new param on visited_vals, if we reach it, caching is unreliable
Sure, but does anybody care? Note what I'd really propose would be
find_base_term-local caching, eliding both the recursion prevention and
the param.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2020-03-19 10:38 ` rguenth at gcc dot gnu.org
@ 2020-03-19 10:38 ` rguenth at gcc dot gnu.org
2020-03-19 10:49 ` rguenth at gcc dot gnu.org
` (24 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-19 10:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 48063
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48063&action=edit
more localized caching
Like this. Martin, can you also check the effect on this one?
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (16 preceding siblings ...)
2020-03-19 10:38 ` rguenth at gcc dot gnu.org
@ 2020-03-19 10:49 ` rguenth at gcc dot gnu.org
2020-03-19 10:50 ` marxin at gcc dot gnu.org
` (23 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-19 10:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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 since we won't ever use non-NULL cached vals which
also means this patch is a no-op and should be worse than the existing
state :/
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (17 preceding siblings ...)
2020-03-19 10:49 ` rguenth at gcc dot gnu.org
@ 2020-03-19 10:50 ` marxin at gcc dot gnu.org
2020-03-19 10:53 ` rguenth at gcc dot gnu.org
` (22 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-19 10:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #24 from Martin Liška <marxin at gcc dot gnu.org> ---
(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 the effect on this one?
>
> We can actually simplify since we won't ever use non-NULL cached vals which
> also means this patch is a no-op and should be worse than the existing
> state :/
So no testing is needed?
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (18 preceding siblings ...)
2020-03-19 10:50 ` marxin at gcc dot gnu.org
@ 2020-03-19 10:53 ` rguenth at gcc dot gnu.org
2020-03-19 10:54 ` rguenth at gcc dot gnu.org
` (21 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-19 10:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #48063|0 |1
is obsolete| |
--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 48064
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48064&action=edit
more localized caching
Updated and simplified patch. Maybe it does help depending on how we have
shared locs for multiple values ...
The update is to not bother updating cache values with non-NULL found ones.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (19 preceding siblings ...)
2020-03-19 10:53 ` rguenth at gcc dot gnu.org
@ 2020-03-19 10:54 ` rguenth at gcc dot gnu.org
2020-03-19 13:12 ` jakub at gcc dot gnu.org
` (20 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-03-19 10:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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 caching
> > >
> > > Like this. Martin, can you also check the effect on this one?
> >
> > We can actually simplify since we won't ever use non-NULL cached vals which
> > also means this patch is a no-op and should be worse than the existing
> > state :/
>
> So no testing is needed?
would be still interesting (but surprising) if it helps (doesn't matter
whether the original or the updated patch, the update is just constant
time improvement)
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (20 preceding siblings ...)
2020-03-19 10:54 ` rguenth at gcc dot gnu.org
@ 2020-03-19 13:12 ` jakub at gcc dot gnu.org
2020-03-19 13:34 ` marxin at gcc dot gnu.org
` (19 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-19 13:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 non-NULL and
length () > 100 were those where it returns
static_reg_base_value[STACK_POINTER_REGNUM].
Which seems exactly like the case for which cselib_sp_based_value_p has been
invented, except it doesn't seem to work in this case the way it should.
Will try to have a look why. Anyway, if that is fixed, perhaps we can just
lower the param to 100?
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (21 preceding siblings ...)
2020-03-19 13:12 ` jakub at gcc dot gnu.org
@ 2020-03-19 13:34 ` marxin at gcc dot gnu.org
2020-03-19 14:42 ` jakub at gcc dot gnu.org
` (18 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-19 13:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #28 from Martin Liška <marxin at gcc dot gnu.org> ---
(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 multiple values ...
>
> The update is to not bother updating cache values with non-NULL found ones.
So this patch is running for the problematic wrf testcase for more that 2h30m..
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (22 preceding siblings ...)
2020-03-19 13:34 ` marxin at gcc dot gnu.org
@ 2020-03-19 14:42 ` jakub at gcc dot gnu.org
2020-03-19 14:57 ` jakub at gcc dot gnu.org
` (17 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-19 14:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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
hard_frame_pointer_adjustment is -1, all we have there is
(insn/f:TI 2695 2874 2696 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4
A8])
(reg:SI 6 bp)) "../../gcc/diagnostic-show-locus.c":3861:1 43 {*pushsi2}
(expr_list:REG_DEAD (reg:SI 6 bp)
(nil)))
some pushes to preserve call saved regs
(insn/f:TI 2699 2698 2700 2 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -508 [0xfffffffffffffe04])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) "../../gcc/diagnostic-show-locus.c":3861:1 1058
{pro_epilogue_adjust_stack_add_si}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -508 [0xfffffffffffffe04])))
(nil))))
(note 2700 2699 17 2 NOTE_INSN_PROLOGUE_END)
Now, the reason we don't mark preserved values sp based unconditionally if they
are sp based is the fear about the prologue and pre-prologue spots, as we need
to disambiguate between sp based and hfp based VALUEs and they normally start
the same as sp based.
Not sure what we can do, perhaps also remember if we've seen in the prologue
some important hfp related instruction, at that point somehow force using
different VALUEs for hfp vs. sp based accesses (dunno if by cselib invalidation
of hfp or of sp) and from that point on mark the clearly sp based VALUEs as
sp_based.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (23 preceding siblings ...)
2020-03-19 14:42 ` jakub at gcc dot gnu.org
@ 2020-03-19 14:57 ` jakub at gcc dot gnu.org
2020-03-20 17:25 ` jakub at gcc dot gnu.org
` (16 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-19 14:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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, voi
}
if (loc == stack_pointer_rtx
- && maybe_ne (hard_frame_pointer_adjustment, -1)
+ && (maybe_ne (hard_frame_pointer_adjustment, -1)
+ || (!frame_pointer_needed && !ACCUMULATE_OUTGOING_ARGS))
&& preserve)
cselib_set_value_sp_based (v);
and with that, retry the statistics gathering to see if now everything > 100 is
NULL?
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (24 preceding siblings ...)
2020-03-19 14:57 ` jakub at gcc dot gnu.org
@ 2020-03-20 17:25 ` jakub at gcc dot gnu.org
2020-03-20 18:26 ` jakub at gcc dot gnu.org
` (15 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-20 17:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 48073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48073&action=edit
gcc10-pr92264-wip.patch
WIP patch to try special casing cselib handling of stack pointer VALUEs.
The intent is that when we first cselib_lookup the stack pointer (e.g. at the
start of a bb), we mark the created VALUE as SP_DERIVED_VALUE_P and when we
lookup sp + CONST_INT, we try to canonicalize that lookup into lookup of that
VALUE + adjusted offset. Grepping e.g. -fdump-rtl-postreload-cselib or
-fdump-rtl-dse2-cselib for ^cselib.value shows that with -O2 -m32 we create
significantly fewer new VALUEs as we can share the VALUEs that are that
SP_DERIVED_VALUE_P VALUE + offset.
Unfortunately, this ICEs during var-tracking due to VALUE canonicalization and
PRESERVED_VALUE_P.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (25 preceding siblings ...)
2020-03-20 17:25 ` jakub at gcc dot gnu.org
@ 2020-03-20 18:26 ` jakub at gcc dot gnu.org
2020-03-20 20:49 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-20 18:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Some incremental progress, but still ICEs...
--- gcc/cselib.c 2020-03-20 17:42:02.333023994 +0100
+++ gcc/cselib.c 2020-03-20 19:23:33.506622424 +0100
@@ -58,6 +58,16 @@
static void cselib_invalidate_mem (rtx);
static void cselib_record_set (rtx, cselib_val *, cselib_val *);
static void cselib_record_sets (rtx_insn *);
+static rtx autoinc_split (rtx, rtx *, machine_mode);
+
+#define PRESERVED_VALUE_P(RTX) \
+ (RTL_FLAG_CHECK1 ("PRESERVED_VALUE_P", (RTX), VALUE)->unchanging)
+
+#define SP_BASED_VALUE_P(RTX) \
+ (RTL_FLAG_CHECK1 ("SP_BASED_VALUE_P", (RTX), VALUE)->jump)
+
+#define SP_DERIVED_VALUE_P(RTX) \
+ (RTL_FLAG_CHECK1 ("SP_DERIVED_VALUE_P", (RTX), VALUE)->call)
struct expand_value_data
{
@@ -122,6 +132,13 @@
if (GET_CODE (x) == VALUE)
return x == v->val_rtx;
+ if (SP_DERIVED_VALUE_P (v->val_rtx) && GET_MODE (x) == Pmode)
+ {
+ rtx xoff = NULL;
+ if (autoinc_split (x, &xoff, memmode) == v->val_rtx && xoff == NULL_RTX)
+ return true;
+ }
+
/* We don't guarantee that distinct rtx's have different hash values,
so we need to do a comparison. */
for (l = v->locs; l; l = l->next)
@@ -256,15 +273,6 @@
void (*cselib_record_sets_hook) (rtx_insn *insn, struct cselib_set *sets,
int n_sets);
-#define PRESERVED_VALUE_P(RTX) \
- (RTL_FLAG_CHECK1 ("PRESERVED_VALUE_P", (RTX), VALUE)->unchanging)
-
-#define SP_BASED_VALUE_P(RTX) \
- (RTL_FLAG_CHECK1 ("SP_BASED_VALUE_P", (RTX), VALUE)->jump)
-
-#define SP_DERIVED_VALUE_P(RTX) \
- (RTL_FLAG_CHECK1 ("SP_DERIVED_VALUE_P", (RTX), VALUE)->call)
-
/* Allocate a struct elt_list and fill in its two elements with the
@@ -497,7 +505,7 @@
};
cselib_val **slot
= cselib_preserved_hash_table->find_slot_with_hash (&lookup,
- v->hash, INSERT);
+ v->hash, INSERT);
gcc_assert (!*slot);
*slot = v;
}
@@ -535,6 +543,28 @@
max_value_regs
= hard_regno_nregs (regno,
GET_MODE (cfa_base_preserved_val->locs->loc));
+
+ /* If cfa_base is sp + const_int, need to preserve also the
+ SP_DERIVED_VALUE_P value. */
+ for (struct elt_loc_list *l = cfa_base_preserved_val->locs;
+ l; l = l->next)
+ if (GET_CODE (l->loc) == PLUS
+ && GET_CODE (XEXP (l->loc, 0)) == VALUE
+ && SP_DERIVED_VALUE_P (XEXP (l->loc, 0))
+ && CONST_INT_P (XEXP (l->loc, 1)))
+ {
+ if (! invariant_or_equiv_p (CSELIB_VAL_PTR (XEXP (l->loc, 0))))
+ {
+ rtx val = cfa_base_preserved_val->val_rtx;
+ rtx_insn *save_cselib_current_insn = cselib_current_insn;
+ cselib_current_insn = l->setting_insn;
+ new_elt_loc_list (CSELIB_VAL_PTR (XEXP (l->loc, 0)),
+ plus_constant (Pmode, val,
+ -UINTVAL (XEXP (l->loc, 1))));
+ cselib_current_insn = save_cselib_current_insn;
+ }
+ break;
+ }
}
else
{
@@ -544,8 +574,7 @@
}
if (cselib_preserve_constants)
- cselib_hash_table->traverse <void *, preserve_constants_and_equivs>
- (NULL);
+ cselib_hash_table->traverse <void *, preserve_constants_and_equivs>
(NULL);
else
{
cselib_hash_table->empty ();
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (26 preceding siblings ...)
2020-03-20 18:26 ` jakub at gcc dot gnu.org
@ 2020-03-20 20:49 ` jakub at gcc dot gnu.org
2020-03-23 9:21 ` jakub at gcc dot gnu.org
` (13 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-20 20:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 48075
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48075&action=edit
gcc10-pr92264-wip.patch
Updated patch, which doesn't ICE anymore, and creates 10500 instead of 12000
VALUEs during var-tracking on diagnostic-show-location.c, which should be a
good thing. But the .s file is smaller and in the *.vartrack dump I see some
NOTE_INSN_VAR_LOCATIONs missing, so apparently it does have bad impact on debug
info quality.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (27 preceding siblings ...)
2020-03-20 20:49 ` jakub at gcc dot gnu.org
@ 2020-03-23 9:21 ` jakub at gcc dot gnu.org
2020-03-23 9:39 ` marxin at gcc dot gnu.org
` (12 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-23 9:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 48081
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48081&action=edit
gcc10-pr92264-wip.patch
Further updated patch, this one passes bootstrap on both x86_64-linux and
i686-linux and according to the gathered statistics results in significantly
fewer cases of visited_vals.length () > 100 in find_base_term, together with
the var-tracking.c small change posted to gcc-patches from 5530878 to 1253101
cases.
But, so far it causes a few regressions:
gcc.dg/guality/pr36728-{1,3}.c and gcc.dg/guality/pr68860-{1,2}.c at various
optimization levels and ICEs on gcc.target/i386/pr88416.c and
gcc.target/i386/sse-{13,23,24,25,26}.c. So far I've looked at pr88416.c and
the problem is that DSE now on:
(insn 10 9 11 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg:DI 17 flags)) "include/ia32intrin.h":262:10 56 {*pushfldi2}
(expr_list:REG_DEAD (reg:DI 17 flags)
(nil)))
(insn 11 10 29 2 (set (reg:DI 85)
(mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0 S8 A8]))
"include/ia32intrin.h":262:10 52 {*popdi1}
(nil))
"optimizes" it into:
(insn 31 9 10 2 (set (reg:DI 89)
(reg:DI 17 flags)) "include/ia32intrin.h":262:10 -1
(nil))
(insn 10 31 11 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg:DI 17 flags)) "include/ia32intrin.h":262:10 56 {*pushfldi2}
(expr_list:REG_DEAD (reg:DI 17 flags)
(nil)))
(insn 11 10 29 2 (set (reg:DI 85)
(reg:DI 89)) "include/ia32intrin.h":262:10 66 {*movdi_internal}
(nil))
This is wrong for 2 reasons. The newly added insn 31 isn't recognized and DSE
doesn't bother trying to recognize it, and when the pop is optimized away into
just reg to reg assignment, the side-effect (post-increment of sp) is lost.
Wonder if DSE shouldn't punt for autoinc (don't remove stores that have them)
or say try to replace the autoinc with register update, and whether it
shouldn't try to recog new insns it creates.
As for the guality failures, I've so far briefly looked only at the first one,
where we end up with an extra
+(note 84 53 54 2 (var_location arg7 (nil)) NOTE_INSN_VAR_LOCATION)
that wasn't there before. Will try to understand this one.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (28 preceding siblings ...)
2020-03-23 9:21 ` jakub at gcc dot gnu.org
@ 2020-03-23 9:39 ` marxin at gcc dot gnu.org
2020-03-26 8:16 ` cvs-commit at gcc dot gnu.org
` (11 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-23 9:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #35 from Martin Liška <marxin at gcc dot gnu.org> ---
The suggested patch helped to reduce compilation to:
2m54s
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (29 preceding siblings ...)
2020-03-23 9:39 ` marxin at gcc dot gnu.org
@ 2020-03-26 8:16 ` cvs-commit at gcc dot gnu.org
2020-03-26 8:22 ` marxin at gcc dot gnu.org
` (10 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-03-26 8:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #36 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:9708ca2be40399d6266bc85c99e085e3fe27a809
commit r10-7392-g9708ca2be40399d6266bc85c99e085e3fe27a809
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Mar 26 09:15:39 2020 +0100
var-tracking: Mark as sp based more VALUEs [PR92264]
With this simple patch, on i686-linux and x86_64-linux with -m32 (no change
for -m64), the find_base_term visited_vals.length () > 100 find_base_term
statistics changed (fbt is before this patch, fbt2 with this patch):
for k in '' '1$'; do for i in 32 64; do for j in fbt fbt2; do \
echo -n "$j $i $k "; LC_ALL=C grep ^$i.*"$k" $j | wc -l; done; done; done
fbt 32 5313355
fbt2 32 4229854
fbt 64 217523
fbt2 64 217523
fbt 32 1$ 1296
fbt2 32 1$ 407
fbt 64 1$ 0
fbt2 64 1$ 0
For frame_pointer_needed functions, we need to wait until we see the
fp_setter insn in the prologue at which point we disassociate the fp based
VALUEs from sp based VALUEs, but for !frame_pointer_needed functions,
we IMHO don't need to wait anything. For ACCUMULATE_OUTGOING_ARGS it isn't
IMHO worth doing anything, as there is a single sp adjustment and so there
is no risk of many thousands deep VALUE chains, but for
!ACCUMULATE_OUTGOING_ARGS the sp keeps changing constantly.
2020-03-26 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/92264
* var-tracking.c (add_stores): Call cselib_set_value_sp_based even
for sp based values in !frame_pointer_needed
&& !ACCUMULATE_OUTGOING_ARGS functions.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (30 preceding siblings ...)
2020-03-26 8:16 ` cvs-commit at gcc dot gnu.org
@ 2020-03-26 8:22 ` marxin at gcc dot gnu.org
2020-03-26 8:26 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-26 8:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #37 from Martin Liška <marxin at gcc dot gnu.org> ---
@Jakub: Can we close it? Or do you plan any other patch for it?
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (31 preceding siblings ...)
2020-03-26 8:22 ` marxin at gcc dot gnu.org
@ 2020-03-26 8:26 ` jakub at gcc dot gnu.org
2020-04-02 12:31 ` cvs-commit at gcc dot gnu.org
` (8 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-26 8:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #38 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No, far from it.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (32 preceding siblings ...)
2020-03-26 8:26 ` jakub at gcc dot gnu.org
@ 2020-04-02 12:31 ` cvs-commit at gcc dot gnu.org
2020-04-02 12:35 ` cvs-commit at gcc dot gnu.org
` (7 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-02 12:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #39 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:2c0fa3ecf70d199af18785702e9e0548fd3ab793
commit r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Apr 2 14:28:14 2020 +0200
cselib: Reuse VALUEs on sp adjustments [PR92264]
As discussed in the PR, if !ACCUMULATE_OUTGOING_ARGS on large functions we
can have hundreds of thousands of stack pointer adjustments and cselib
creates a new VALUE after each sp adjustment, which form extremely deep
VALUE chains, which is very harmful e.g. for find_base_term.
E.g. if we have
sp -= 4
sp -= 4
sp += 4
sp += 4
sp -= 4
sp += 4
that means 7 VALUEs, one for the sp at beginning (val1), than val2 = val1 -
4, then val3 = val2 - 4, then val4 = val3 + 4, then val5 = val4 + 4, then
val6 = val5 - 4, then val7 = val6 + 4.
This patch tweaks cselib, so that it is smarter about sp adjustments.
When cselib_lookup (stack_pointer_rtx, Pmode, 1, VOIDmode) and we know
nothing about sp yet (this happens at the start of the function, for
non-var-tracking also after cselib_reset_table and for var-tracking after
processing fp_setter insn where we forget about former sp values because
that is now hfp related while everything after it is sp related), we
look it up normally, but in addition to what we have been doing before
we mark the VALUE as SP_DERIVED_VALUE_P. Further lookups of sp + offset
are then special cased, so that it is canonicalized to that
SP_DERIVED_VALUE_P VALUE + CONST_INT (if possible). So, for the above,
we get val1 with SP_DERIVED_VALUE_P set, then val2 = val1 - 4, val3 = val1
-
8 (note, no longer val2 - 4!), then we get val2 again, val1 again, val2
again, val1 again.
In the find_base_term visited_vals.length () > 100 find_base_term
statistics during combined x86_64-linux and i686-linux bootstrap+regtest
cycle, without the patch I see:
find_base_term > 100
returning NULL returning non-NULL
32-bit compilations 4229178 407
64-bit compilations 217523 0
with largest visited_vals.length () when returning non-NULL being 206.
With the patch the same numbers are:
32-bit compilations 1249588 135
64-bit compilations 3510 0
with largest visited_vals.length () when returning non-NULL being 173.
This shows significant reduction of the deep VALUE chains.
On powerpc64{,le}-linux, these stats didn't change at all, we have
1008 0
for all of -m32, -m64 and little-endian -m64, just the
gcc.dg/pr85180.c and gcc.dg/pr87985.c testcases which are unrelated to sp.
My earlier version of the patch, which contained just the rtl.h and
cselib.c
changes, regressed some tests:
gcc.dg/guality/{pr36728-{1,3},pr68860-{1,2}}.c
gcc.target/i386/{pr88416,sse-{13,23,24,25,26}}.c
The problem with the former tests was worse debug info, where with -m32
where arg7 was passed in a stack slot we though a push later on might have
invalidated it, when it couldn't. This is something I've solved with the
var-tracking.c (vt_initialize) changes. In those problematic functions, we
create a cfa_base VALUE (argp) and want to record that at the start of
the function the argp VALUE is sp + off and also record that current sp
VALUE is argp's VALUE - off. The second permanent equivalence didn't make
it after the patch though, because cselib_add_permanent_equiv will
cselib_lookup the value of the expression it wants to add as the
equivalence
and if it is the same VALUE as we are calling it on, it doesn't do
anything;
and due to the cselib changes for sp based accesses that is exactly what
happened. By reversing the order of the cselib_add_permanent_equiv calls
we
get both equivalences though and thus are able to canonicalize the sp based
accesses in var-tracking to the cfa_base value + offset.
The i386 FAILs were all ICEs, where we had pushf instruction pushing flags
and then pop pseudo reading that value again. With the cselib changes,
cselib during RTL DSE is able to see through the sp adjustment and wanted
to replace_read what was done pushf, by moving the flags register into a
pseudo and replace the memory read in the pop with that pseudo. That is
wrong for two reasons: one is that the backend doesn't have an instruction
to move the flags hard register into some other register, but replace_read
has been validating just the mem -> pseudo replacement and not the insns
emitted by copy_to_mode_reg. And the second issue is that it is obviously
wrong to replace a stack pop which contains stack post-increment by a copy
of pseudo into destination. dse.c has some code to handle RTX_AUTOINC, but
only uses it when actually removing stores and only when there is REG_INC
note (stack RTX_AUTOINC does not have those), in check_for_inc_dec* where
it emits the reg adjustment(s) before the insn that is going to be deleted.
replace_read doesn't remove the insn, so if it e.g. contained REG_INC note,
it would be kept there and we might have the RTX_AUTOINC not just in *loc,
but other spots.
So, the dse.c changes try to validate the added insns and punt on all
RTX_AUTOINC in *loc. Furthermore, it seems that with the cselib.c changes
on the gfortran.dg/pr87360.f90 and gcc.target/i386/pr88416.c testcases
check_for_inc_dec{,_1} happily throws stack pointer autoinc on the floor,
which is also wrong. While we could perhaps do the for_each_inc_dec
call regardless of whether we have REG_INC note or not, we aren't prepared
to handle e.g. REG_ARGS_SIZE distribution and thus could end up with wrong
unwind info or ICEs during dwarf2cfi.c. So the patch also punts on those,
after all, if we'd in theory managed to try to optimize such pushes before,
we'd create wrong-code.
On x86_64-linux and i686-linux, the patch has some minor debug info
coverage
differences, but it doesn't appear very significant to me.
https://github.com/pmachata/dwlocstat tool gives (where before is vanilla
trunk + the rtl.h patch but not {cselib,var-tracking,dse}.c
--enable-checking=yes,rtl,extra bootstrapped, then
{cselib,var-tracking,dse}.c
hunks applied and make cc1plus, while after is trunk with the whole patch
applied).
64-bit cc1plus
before
cov% samples cumul
0..10 1232756/48% 1232756/48%
11..20 31089/1% 1263845/49%
21..30 39172/1% 1303017/51%
31..40 38853/1% 1341870/52%
41..50 47473/1% 1389343/54%
51..60 45171/1% 1434514/56%
61..70 69393/2% 1503907/59%
71..80 61988/2% 1565895/61%
81..90 104528/4% 1670423/65%
91..100 875402/34% 2545825/100%
after
cov% samples cumul
0..10 1233238/48% 1233238/48%
11..20 31086/1% 1264324/49%
21..30 39157/1% 1303481/51%
31..40 38819/1% 1342300/52%
41..50 47447/1% 1389747/54%
51..60 45151/1% 1434898/56%
61..70 69379/2% 1504277/59%
71..80 61946/2% 1566223/61%
81..90 104508/4% 1670731/65%
91..100 875094/34% 2545825/100%
32-bit cc1plus
before
cov% samples cumul
0..10 1231221/48% 1231221/48%
11..20 30992/1% 1262213/49%
21..30 36422/1% 1298635/51%
31..40 35793/1% 1334428/52%
41..50 47102/1% 1381530/54%
51..60 41201/1% 1422731/56%
61..70 65467/2% 1488198/58%
71..80 59560/2% 1547758/61%
81..90 104076/4% 1651834/65%
91..100 881879/34% 2533713/100%
after
cov% samples cumul
0..10 1230469/48% 1230469/48%
11..20 30390/1% 1260859/49%
21..30 36362/1% 1297221/51%
31..40 36042/1% 1333263/52%
41..50 47619/1% 1380882/54%
51..60 41674/1% 1422556/56%
61..70 65849/2% 1488405/58%
71..80 59857/2% 1548262/61%
81..90 104178/4% 1652440/65%
91..100 881273/34% 2533713/100%
2020-04-02 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/92264
* rtl.h (struct rtx_def): Mention that call bit is used as
SP_DERIVED_VALUE_P in cselib.c.
* cselib.c (SP_DERIVED_VALUE_P): Define.
(PRESERVED_VALUE_P, SP_BASED_VALUE_P): Move definitions earlier.
(cselib_hasher::equal): Handle equality between SP_DERIVED_VALUE_P
val_rtx and sp based expression where offsets cancel each other.
(preserve_constants_and_equivs): Formatting fix.
(cselib_reset_table): Add reverse op loc to SP_DERIVED_VALUE_P
locs list for cfa_base_preserved_val if needed. Formatting fix.
(autoinc_split): If the to be returned value is a REG, MEM or
VALUE which has SP_DERIVED_VALUE_P + CONST_INT as one of its
locs, return the SP_DERIVED_VALUE_P VALUE and adjust *off.
(rtx_equal_for_cselib_1): Call autoinc_split even if both
expressions are PLUS in Pmode with CONST_INT second operands.
Handle SP_DERIVED_VALUE_P cases.
(cselib_hash_plus_const_int): New function.
(cselib_hash_rtx): Use it for PLUS in Pmode with CONST_INT
second operand, as well as for PRE_DEC etc. that ought to be
hashed the same way.
(cselib_subst_to_values): Substitute PLUS with Pmode and
CONST_INT operand if the first operand is a VALUE which has
SP_DERIVED_VALUE_P + CONST_INT as one of its locs for the
SP_DERIVED_VALUE_P + adjusted offset.
(cselib_lookup_1): When creating a new VALUE for stack_pointer_rtx,
set SP_DERIVED_VALUE_P on it. Set PRESERVED_VALUE_P when adding
SP_DERIVED_VALUE_P PRESERVED_VALUE_P subseted VALUE location.
* var-tracking.c (vt_initialize): Call cselib_add_permanent_equiv
on the sp value before calling cselib_add_permanent_equiv on the
cfa_base value.
* dse.c (check_for_inc_dec_1, check_for_inc_dec): Punt on
RTX_AUTOINC
in the insn without REG_INC note.
(replace_read): Punt on RTX_AUTOINC in the *loc being replaced.
Punt on invalid insns added by copy_to_mode_reg. Formatting fixes.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (33 preceding siblings ...)
2020-04-02 12:31 ` cvs-commit at gcc dot gnu.org
@ 2020-04-02 12:35 ` cvs-commit at gcc dot gnu.org
2020-04-02 14:22 ` marxin at gcc dot gnu.org
` (6 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-02 12:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #40 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:86c924113208f58fdda24078c9cc9285ee8000cd
commit r10-7516-g86c924113208f58fdda24078c9cc9285ee8000cd
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Apr 2 14:34:42 2020 +0200
params: Decrease -param=max-find-base-term-values= default [PR92264]
For the PR in question, my proposal would be to also lower
-param=max-find-base-term-values=
default from 2000 to 200 after this, at least in the above 4
bootstraps/regtests there is nothing that would ever result in
find_base_term returning non-NULL with more than 200 VALUEs being
processed.
2020-04-02 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/92264
* params.opt (-param=max-find-base-term-values=): Decrease default
from 2000 to 200.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (34 preceding siblings ...)
2020-04-02 12:35 ` cvs-commit at gcc dot gnu.org
@ 2020-04-02 14:22 ` marxin at gcc dot gnu.org
2020-04-02 14:28 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-04-02 14:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #41 from Martin Liška <marxin at gcc dot gnu.org> ---
The current master does:
$ time gfortran module_configure.fppized.f90 -c -march=znver2 -std=legacy
-fconvert=big-endian -fno-openmp -Ofast -march=znver2 -g
...
real 2m21.190s
user 2m20.487s
sys 0m0.647s
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (35 preceding siblings ...)
2020-04-02 14:22 ` marxin at gcc dot gnu.org
@ 2020-04-02 14:28 ` jakub at gcc dot gnu.org
2020-04-02 14:37 ` marxin at gcc dot gnu.org
` (4 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-02 14:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #42 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (36 preceding siblings ...)
2020-04-02 14:28 ` jakub at gcc dot gnu.org
@ 2020-04-02 14:37 ` marxin at gcc dot gnu.org
2020-04-02 14:40 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-04-02 14:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #43 from Martin Liška <marxin at gcc dot gnu.org> ---
(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 those 141s are with checking compiler or not.
These 140 are with default checking for current master which is checking
enabled. That said, I would close this.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (37 preceding siblings ...)
2020-04-02 14:37 ` marxin at gcc dot gnu.org
@ 2020-04-02 14:40 ` jakub at gcc dot gnu.org
2020-04-03 18:47 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
41 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-02 14:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #44 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed then.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (38 preceding siblings ...)
2020-04-02 14:40 ` jakub at gcc dot gnu.org
@ 2020-04-03 18:47 ` cvs-commit at gcc dot gnu.org
2020-04-03 23:48 ` cvs-commit at gcc dot gnu.org
2020-04-07 23:56 ` cvs-commit at gcc dot gnu.org
41 siblings, 0 replies; 42+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-03 18:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #45 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <law@gcc.gnu.org>:
https://gcc.gnu.org/g:b949f8e2acb49273b2f08ecaa3bc7128baaad850
commit r10-7544-gb949f8e2acb49273b2f08ecaa3bc7128baaad850
Author: Jeff Law <law@redhat.com>
Date: Fri Apr 3 12:46:13 2020 -0600
Fix va-arg-22.c at -O1 on m32r.
PR rtl-optimization/92264
* config/m32r/m32r.c (m32r_output_block_move): Properly account for
post-increment addressing of source operands as well as residuals
when computing any adjustments to the input pointer.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (39 preceding siblings ...)
2020-04-03 18:47 ` cvs-commit at gcc dot gnu.org
@ 2020-04-03 23:48 ` cvs-commit at gcc dot gnu.org
2020-04-07 23:56 ` cvs-commit at gcc dot gnu.org
41 siblings, 0 replies; 42+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-03 23:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #46 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <law@gcc.gnu.org>:
https://gcc.gnu.org/g:7f26e60c2600f0a676fc9370390ebf0a3c78f31c
commit r10-7548-g7f26e60c2600f0a676fc9370390ebf0a3c78f31c
Author: Jeff Law <law@redhat.com>
Date: Fri Apr 3 17:47:18 2020 -0600
Fix stdarg-3 regression on xstormy16 port
PR rtl-optimization/92264
* config/stormy16/stormy16.c (xstormy16_preferred_reload_class):
Handle
reloading of auto-increment addressing modes.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
[not found] <bug-92264-4@http.gcc.gnu.org/bugzilla/>
` (40 preceding siblings ...)
2020-04-03 23:48 ` cvs-commit at gcc dot gnu.org
@ 2020-04-07 23:56 ` cvs-commit at gcc dot gnu.org
41 siblings, 0 replies; 42+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-07 23:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #47 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <law@gcc.gnu.org>:
https://gcc.gnu.org/g:14162197fd4cf0e3a848d32bd9385876e1b1f249
commit r10-7609-g14162197fd4cf0e3a848d32bd9385876e1b1f249
Author: Jeff Law <law@redhat.com>
Date: Tue Apr 7 17:55:00 2020 -0600
Fix a variety of testsuite failures on the H8 after recent cselib changes
PR rtl-optimization/92264
* config/h8300/h8300.md (mov;add peephole2): Avoid applying when
the destination is the stack pointer.
^ permalink raw reply [flat|nested] 42+ messages in thread