* [Bug target/111600] [14.0 regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
@ 2023-09-26 17:41 ` pinskia at gcc dot gnu.org
2023-09-27 7:36 ` [Bug target/111600] [14 Regression] " rguenth at gcc dot gnu.org
` (33 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-09-26 17:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The new (target) builtins could cause increased compile time ...
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
2023-09-26 17:41 ` [Bug target/111600] " pinskia at gcc dot gnu.org
@ 2023-09-27 7:36 ` rguenth at gcc dot gnu.org
2023-09-27 7:47 ` schwab@linux-m68k.org
` (32 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-09-27 7:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[14.0 regression] RISC-V |[14 Regression] RISC-V
|bootstrap time regression |bootstrap time regression
CC| |rguenth at gcc dot gnu.org
Target Milestone|--- |14.0
Keywords| |needs-bisection
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can you attach the dwarf2out.cc preprocessed source?
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
2023-09-26 17:41 ` [Bug target/111600] " pinskia at gcc dot gnu.org
2023-09-27 7:36 ` [Bug target/111600] [14 Regression] " rguenth at gcc dot gnu.org
@ 2023-09-27 7:47 ` schwab@linux-m68k.org
2023-09-27 7:50 ` schwab@linux-m68k.org
` (31 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: schwab@linux-m68k.org @ 2023-09-27 7:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
Here are the build times of the stage1 compiler:
20230714 21573
20230722 19932 -7.6%
20230728 21608 +8.4%
20230804 21841 +1.0%
20230811 25016 +14.5%
20230818 25429 +1.7%
20230825 25872 +1.7%
20230901 25965 +0.4%
20230908 28824 +11.0%
20230915 30926 +7.3%
20230922 40180 +30.0%
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (2 preceding siblings ...)
2023-09-27 7:47 ` schwab@linux-m68k.org
@ 2023-09-27 7:50 ` schwab@linux-m68k.org
2023-09-27 8:00 ` rguenth at gcc dot gnu.org
` (30 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: schwab@linux-m68k.org @ 2023-09-27 7:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> ---
Created attachment 56000
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56000&action=edit
dwarf2out.ii
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (3 preceding siblings ...)
2023-09-27 7:50 ` schwab@linux-m68k.org
@ 2023-09-27 8:00 ` rguenth at gcc dot gnu.org
2023-09-27 13:36 ` schwab@linux-m68k.org
` (29 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-09-27 8:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
On x86_64-linux the compile-time of the same dwarf2out.ii the
slowdown between r14-2510-g3d0ca8b55b9a88 and r14-4258-gc9837443075277
is less than 2.5% (three runs, fastest vs slowest).
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (4 preceding siblings ...)
2023-09-27 8:00 ` rguenth at gcc dot gnu.org
@ 2023-09-27 13:36 ` schwab@linux-m68k.org
2023-09-27 17:50 ` palmer at gcc dot gnu.org
` (28 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: schwab@linux-m68k.org @ 2023-09-27 13:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #6 from Andreas Schwab <schwab@linux-m68k.org> ---
$ wc -l gcc-*/Build/gcc/insn-opinit.cc
6996 gcc-20230714/Build/gcc/insn-opinit.cc
6591 gcc-20230722/Build/gcc/insn-opinit.cc
6809 gcc-20230728/Build/gcc/insn-opinit.cc
6967 gcc-20230804/Build/gcc/insn-opinit.cc
10451 gcc-20230811/Build/gcc/insn-opinit.cc
11227 gcc-20230818/Build/gcc/insn-opinit.cc
11464 gcc-20230825/Build/gcc/insn-opinit.cc
11664 gcc-20230901/Build/gcc/insn-opinit.cc
12166 gcc-20230908/Build/gcc/insn-opinit.cc
13016 gcc-20230915/Build/gcc/insn-opinit.cc
16788 gcc-20230922/Build/gcc/insn-opinit.cc
$ wc -l gcc-*/Build/gcc/insn-output.cc
858964 gcc-20230714/Build/gcc/insn-output.cc
708403 gcc-20230722/Build/gcc/insn-output.cc
753003 gcc-20230728/Build/gcc/insn-output.cc
753971 gcc-20230804/Build/gcc/insn-output.cc
879098 gcc-20230811/Build/gcc/insn-output.cc
903026 gcc-20230818/Build/gcc/insn-output.cc
920033 gcc-20230825/Build/gcc/insn-output.cc
948627 gcc-20230901/Build/gcc/insn-output.cc
993341 gcc-20230908/Build/gcc/insn-output.cc
1213716 gcc-20230915/Build/gcc/insn-output.cc
1527729 gcc-20230922/Build/gcc/insn-output.cc
$ wc -l gcc-*/Build/gcc/insn-emit.cc
633220 gcc-20230714/Build/gcc/insn-emit.cc
521442 gcc-20230722/Build/gcc/insn-emit.cc
551484 gcc-20230728/Build/gcc/insn-emit.cc
553655 gcc-20230804/Build/gcc/insn-emit.cc
695596 gcc-20230811/Build/gcc/insn-emit.cc
715442 gcc-20230818/Build/gcc/insn-emit.cc
723656 gcc-20230825/Build/gcc/insn-emit.cc
740419 gcc-20230901/Build/gcc/insn-emit.cc
776695 gcc-20230908/Build/gcc/insn-emit.cc
860129 gcc-20230915/Build/gcc/insn-emit.cc
1093024 gcc-20230922/Build/gcc/insn-emit.cc
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (5 preceding siblings ...)
2023-09-27 13:36 ` schwab@linux-m68k.org
@ 2023-09-27 17:50 ` palmer at gcc dot gnu.org
2023-09-27 18:22 ` schwab@linux-m68k.org
` (27 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: palmer at gcc dot gnu.org @ 2023-09-27 17:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
palmer at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palmer at gcc dot gnu.org,
| |vineetg at gcc dot gnu.org
--- Comment #7 from palmer at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #3)
> Here are the build times of the stage1 compiler:
>
> 20230714 21573
> 20230722 19932 -7.6%
> 20230728 21608 +8.4%
> 20230804 21841 +1.0%
> 20230811 25016 +14.5%
> 20230818 25429 +1.7%
> 20230825 25872 +1.7%
> 20230901 25965 +0.4%
> 20230908 28824 +11.0%
> 20230915 30926 +7.3%
> 20230922 40180 +30.0%
Did anything else change? The latest binutils has better debug support, so I
could imagine us ending up with some longer compiler times as a result -- there
has to be more than just that here, though.
Aside from that we have had a ton of vector codegen go in over the last few
months, but this is a pretty huge increase so I agree it's worrisome. I'm
adding Vineet to the CC list, as he's been doing some SPEC runs. I don't think
we've had any major runtime regressions, but looks like dwarf2out.cc times have
crept up a bit which is also worrisome.
Also what exactly are you timing? Native boostraps on QEMU?
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (6 preceding siblings ...)
2023-09-27 17:50 ` palmer at gcc dot gnu.org
@ 2023-09-27 18:22 ` schwab@linux-m68k.org
2023-09-28 8:06 ` schwab@linux-m68k.org
` (26 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: schwab@linux-m68k.org @ 2023-09-27 18:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #8 from Andreas Schwab <schwab@linux-m68k.org> ---
Native on HiFive Unleashed.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (7 preceding siblings ...)
2023-09-27 18:22 ` schwab@linux-m68k.org
@ 2023-09-28 8:06 ` schwab@linux-m68k.org
2023-09-28 9:47 ` rguenth at gcc dot gnu.org
` (25 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: schwab@linux-m68k.org @ 2023-09-28 8:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #9 from Andreas Schwab <schwab@linux-m68k.org> ---
Another problem is that compiling insn-opinit.cc requires insane amount of
stack space.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (8 preceding siblings ...)
2023-09-28 8:06 ` schwab@linux-m68k.org
@ 2023-09-28 9:47 ` rguenth at gcc dot gnu.org
2023-09-28 13:14 ` cvs-commit at gcc dot gnu.org
` (24 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-09-28 9:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=111622
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Compiling insn-opinit.ii with a cross compiler at -O2 shows (checking enabled
but -fno-checking)
scheduling : 34.48 ( 47%) 0.01 ( 1%) 34.50 ( 46%)
7576k ( 1%)
I don't run into the stack space issue with using the cross, but GCC tries
to up the stack limit and appearantly qemu doesn't implement that. With
a hard limit of 8MB (our default soft limit) I hit the recursion issue
also with a cross.
The backtrace is
Program received signal SIGSEGV, Segmentation fault.
0x0000000001808aff in range_query::get_tree_range (this=this@entry=0x5f540f0,
r=..., expr=expr@entry=<integer_cst 0x7fffeecd7780>, stmt=<optimized out>) at
/space/rguenther/src/gcc/gcc/value-query.cc:163
163 i.set (TREE_TYPE (expr), w, w);
(gdb) bt
#0 0x0000000001808aff in range_query::get_tree_range
(this=this@entry=0x5f540f0, r=...,
expr=expr@entry=<integer_cst 0x7fffeecd7780>, stmt=<optimized out>) at
/space/rguenther/src/gcc/gcc/value-query.cc:163
#1 0x000000000273f7c6 in gimple_ranger::range_of_expr (this=0x5f540f0, r=...,
expr=<integer_cst 0x7fffeecd7780>,
stmt=<optimized out>) at /space/rguenther/src/gcc/gcc/gimple-range.cc:86
#2 0x00000000016dd2ce in get_range (val=val@entry=<integer_cst
0x7fffeecd7780>, stmt=<optimized out>,
minmax=minmax@entry=0x7fffff7ff9b0, rvals=<optimized out>) at
/space/rguenther/src/gcc/gcc/tree-ssa-strlen.cc:219
#3 0x0000000001358656 in get_offset_range (x=<integer_cst 0x7fffeecd7780>,
stmt=stmt@entry=<gimple_assign 0x7fffe9c22e10>, r=r@entry=0x7fffff7ffaf0,
rvals=<optimized out>)
at /space/rguenther/src/gcc/gcc/pointer-query.cc:93
#4 0x000000000135bd53 in handle_mem_ref (qry=0x41938e8, snlim=...,
pref=0x7fffff7ffd90, ostype=<optimized out>,
stmt=<gimple_assign 0x7fffe9c22e10>, mref=<mem_ref 0x7fffef391578>)
at /space/rguenther/src/gcc/gcc/pointer-query.cc:1995
#5 compute_objsize_r (ptr=<mem_ref 0x7fffef391578>, stmt=<gimple_assign
0x7fffe9c22e10>, addr=addr@entry=false,
ostype=ostype@entry=0, pref=pref@entry=0x7fffff7ffd90, snlim=...,
qry=0x41938e8)
at /space/rguenther/src/gcc/gcc/pointer-query.cc:2262
#6 0x000000000136022a in compute_objsize (ptr=<optimized out>,
stmt=stmt@entry=<gimple_assign 0x7fffe9c22e10>,
ostype=ostype@entry=0, pref=0x7fffff7ffd90, ptr_qry=<optimized out>,
ptr_qry@entry=0x41938e8)
at /space/rguenther/src/gcc/gcc/pointer-query.cc:2368
#7 0x00000000013603f6 in pointer_query::get_ref (this=this@entry=0x41938e8,
ptr=ptr@entry=<mem_ref 0x7fffef391578>,
stmt=stmt@entry=<gimple_assign 0x7fffe9c22e10>,
pref=pref@entry=0x7fffff7ffd90, ostype=ostype@entry=0)
at /space/rguenther/src/gcc/gcc/pointer-query.cc:1516
#8 0x00000000010d8a6d in (anonymous
namespace)::pass_waccess::check_dangling_stores (this=this@entry=0x4193890,
bb=<basic_block 0x7fffe7bc6900 (21227)>, stores=..., bbs=...)
at /space/rguenther/src/gcc/gcc/gimple-ssa-warn-access.cc:4561
...
#18067 0x00000000010e1303 in (anonymous
namespace)::pass_waccess::check_dangling_stores (this=0x4193890)
at /space/rguenther/src/gcc/gcc/gimple-ssa-warn-access.cc:4640
4640 check_dangling_stores (EXIT_BLOCK_PTR_FOR_FN (m_func), stores, bbs);
I'll fix that.
I also see insn-emit.cc compile (of the cross compiler) requiring 8GB of memory
and multiple minutes (with a GCC 7 host compiler).
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (9 preceding siblings ...)
2023-09-28 9:47 ` rguenth at gcc dot gnu.org
@ 2023-09-28 13:14 ` cvs-commit at gcc dot gnu.org
2023-10-02 15:03 ` rdapp at gcc dot gnu.org
` (23 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-09-28 13:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:f194c684a28a5d449bd034a2c604d04ba465e4fe
commit r14-4308-gf194c684a28a5d449bd034a2c604d04ba465e4fe
Author: Richard Biener <rguenther@suse.de>
Date: Thu Sep 28 11:51:30 2023 +0200
target/111600 - avoid deep recursion in access diagnostics
pass_waccess::check_dangling_stores uses recursion to traverse the CFG.
The following changes this to use a heap allocated worklist to avoid
blowing the stack.
Instead of using a better iteration order it tries hard to preserve
the current iteration order to avoid new false positives to pop up
since the set of stores we keep track isn't properly modeling flow,
so what is diagnosed and what not is quite random. We are also
lacking the ideal RPO compute on the inverted graph that would just
ignore reverse unreachable code (as the current iteration scheme does).
PR target/111600
* gimple-ssa-warn-access.cc (pass_waccess::check_dangling_stores):
Use a heap allocated worklist for CFG traversal instead of
recursion.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (10 preceding siblings ...)
2023-09-28 13:14 ` cvs-commit at gcc dot gnu.org
@ 2023-10-02 15:03 ` rdapp at gcc dot gnu.org
2023-10-02 15:28 ` kito at gcc dot gnu.org
` (22 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-10-02 15:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
Robin Dapp <rdapp at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at gcc dot gnu.org
--- Comment #12 from Robin Dapp <rdapp at gcc dot gnu.org> ---
We're really at a point where just building becomes a burden and turnaround
times are annoyingly high. My suspicion is that the large number of modes
combined with the number of insn patterns slows us down. Juzhe added a lot of
VLS patterns (or rather added VLS modes to existing patterns) around the
Cauldron and this is where we saw the largest relative slowdown.
Maybe we need to bite the bullet and not use the convenience helpers anymore or
at least very sparingly? I'm going to make some experiments on Wednesday to
see where that gets us.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (11 preceding siblings ...)
2023-10-02 15:03 ` rdapp at gcc dot gnu.org
@ 2023-10-02 15:28 ` kito at gcc dot gnu.org
2023-10-03 15:26 ` kito at gcc dot gnu.org
` (21 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: kito at gcc dot gnu.org @ 2023-10-02 15:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
Kito Cheng <kito at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kito at gcc dot gnu.org
--- Comment #13 from Kito Cheng <kito at gcc dot gnu.org> ---
I guess we may need something like this g:703417a0 for those generator for md
file?
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (12 preceding siblings ...)
2023-10-02 15:28 ` kito at gcc dot gnu.org
@ 2023-10-03 15:26 ` kito at gcc dot gnu.org
2023-10-04 6:46 ` rguenth at gcc dot gnu.org
` (20 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: kito at gcc dot gnu.org @ 2023-10-03 15:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #14 from Kito Cheng <kito at gcc dot gnu.org> ---
Some info for generated files:
---------------------------------------------------------------------------------
File blank comment code
---------------------------------------------------------------------------------
insn-output.cc 3532 35029 1631721
insn-emit.cc 37288 40240 1161790
insn-recog.cc 44203 23 428130
insn-attrtab.cc 1014 30 169934
gimple-match-2.cc 77 2 49303
gimple-match-9.cc 29 2 33073
insn-extract.cc 241 8 28934
gimple-match-1.cc 105 2 25578
gimple-match-8.cc 114 2 24348
options.cc 325 1 24175
insn-opinit.cc 12 6 20156
generic-match-9.cc 55 2 19080
gimple-match-3.cc 98 2 17433
gimple-match-7.cc 108 2 17105
gimple-match-10.cc 129 2 16888
gimple-match-6.cc 115 2 16836
gimple-match-4.cc 97 2 16830
gimple-match-5.cc 99 2 16377
generic-match-3.cc 57 2 16138
options-save.cc 1037 19 15121
generic-match-4.cc 70 2 14095
gtype-desc.cc 679 30 12597
insn-automata.cc 73 11 11735
generic-match-2.cc 60 2 11543
generic-match-1.cc 56 2 11504
generic-match-7.cc 66 2 10238
generic-match-5.cc 71 2 10231
generic-match-10.cc 66 2 9860
generic-match-6.cc 61 2 9853
generic-match-8.cc 53 2 9651
insn-modes.cc 750 410 7655
min-insn-modes.cc 9 2 2280
gengtype-lex.cc 398 424 2126
insn-preds.cc 146 32 1515
insn-dfatab.cc 31 3 1230
insn-latencytab.cc 26 3 1142
gcc-ranlib.cc 55 49 196
insn-enums.cc 6 2 173
insn-peep.cc 7 2 34
cc1-checksum.cc 0 0 3
cc1plus-checksum.cc 0 0 3
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (13 preceding siblings ...)
2023-10-03 15:26 ` kito at gcc dot gnu.org
@ 2023-10-04 6:46 ` rguenth at gcc dot gnu.org
2023-10-04 8:17 ` rdapp at gcc dot gnu.org
` (19 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-10-04 6:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think despite looking at the total size of the files it would be nice to see
if some of the large functions take a lot of compile-time (and where) and see
whether some more intelligent code emission helps. Like I pointed out stuff
like
insn_code
maybe_code_for_pred_indexed_load (int arg0, machine_mode arg1, machine_mode
arg2)
{
if (arg0 == 84
&& arg1 == E_RVVMF8x2QImode
&& arg2 == E_RVVMF8QImode)
return CODE_FOR_pred_indexed_oloadrvvmf8x2qirvvmf8qi;
if (arg0 == 85
&& arg1 == E_RVVMF8x2QImode
&& arg2 == E_RVVMF8QImode)
return CODE_FOR_pred_indexed_uloadrvvmf8x2qirvvmf8qi;
if (arg0 == 84
&& arg1 == E_RVVMF8x3QImode
&& arg2 == E_RVVMF8QImode)
return CODE_FOR_pred_indexed_oloadrvvmf8x3qirvvmf8qi;
if (arg0 == 85
&& arg1 == E_RVVMF8x3QImode
&& arg2 == E_RVVMF8QImode)
...
that requires GCC to do a lot of jump threading to arrive at essentially
nested switches or a fancy lookup table (combining all args) to get this
to a point where it also behaves in a sane way at runtime (the above at -O0
would also execute very slowly).
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (14 preceding siblings ...)
2023-10-04 6:46 ` rguenth at gcc dot gnu.org
@ 2023-10-04 8:17 ` rdapp at gcc dot gnu.org
2023-10-04 9:07 ` rguenther at suse dot de
` (18 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-10-04 8:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #16 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Confirming that it's the compilation of insn-emit.cc which takes > 10 minutes.
The rest (including auto generating of files) is reasonably fast. Going to do
some experiments with it and see which pass takes the most time.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (15 preceding siblings ...)
2023-10-04 8:17 ` rdapp at gcc dot gnu.org
@ 2023-10-04 9:07 ` rguenther at suse dot de
2023-10-04 12:50 ` rdapp at gcc dot gnu.org
` (17 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rguenther at suse dot de @ 2023-10-04 9:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 4 Oct 2023, rdapp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
>
> --- Comment #16 from Robin Dapp <rdapp at gcc dot gnu.org> ---
> Confirming that it's the compilation of insn-emit.cc which takes > 10 minutes.
> The rest (including auto generating of files) is reasonably fast. Going to do
> some experiments with it and see which pass takes the most time.
And in which function(s) please. IIRC -Q will announce each function
entering post-IPA passses (announce_function), you could eventually
dump the current time there as well.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (16 preceding siblings ...)
2023-10-04 9:07 ` rguenther at suse dot de
@ 2023-10-04 12:50 ` rdapp at gcc dot gnu.org
2023-10-04 13:13 ` rguenth at gcc dot gnu.org
` (16 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-10-04 12:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #18 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Just finished an initial timing run, sorted, first 10:
Time variable usr sys wall
GGC
phase opt and generate : 567.60 ( 97%) 38.23 ( 87%) 608.13 ( 97%)
22060M ( 90%)
callgraph functions expansion : 491.16 ( 84%) 31.48 ( 72%) 524.60 ( 83%)
18537M ( 75%)
integration : 90.09 ( 15%) 11.68 ( 27%) 103.25 ( 16%)
13408M ( 54%)
tree CFG cleanup : 74.43 ( 13%) 1.02 ( 2%) 74.66 ( 12%)
201M ( 1%)
callgraph ipa passes : 70.16 ( 12%) 6.21 ( 14%) 76.66 ( 12%)
2921M ( 12%)
tree STMT verifier : 64.03 ( 11%) 3.52 ( 8%) 67.61 ( 11%)
0 ( 0%)
tree CCP : 44.78 ( 8%) 2.91 ( 7%) 47.65 ( 8%)
314M ( 1%)
integrated RA : 42.82 ( 7%) 0.86 ( 2%) 42.71 ( 7%)
880M ( 4%)
`- tree CFG cleanup : 30.57 ( 5%) 0.38 ( 1%) 32.03 ( 5%)
198M ( 1%)
`- tree CCP : 29.78 ( 5%) 0.05 ( 0%) 29.87 ( 5%)
168M ( 1%)
tree SSA verifier : 28.07 ( 5%) 1.42 ( 3%) 30.91 ( 5%)
0 ( 0%)
Per-function sorted expansion time (first 10):
insn_code maybe_code_for_pred_indexed_store(int, machine_mode, machine_mode);
3.050000
insn_code maybe_code_for_pred_indexed_load(int, machine_mode, machine_mode);
2.680000
insn_code maybe_code_for_pred(int, machine_mode); 1.490000
rtx_insn* gen_split_4213(rtx_insn*, rtx_def**); 1.330000
insn_code maybe_code_for_pred_scalar(rtx_code, machine_mode); 1.180000
rtx_insn* gen_split_1266(rtx_insn*, rtx_def**); 0.700000
insn_code maybe_code_for_pred_slide(int, machine_mode); 0.510000
insn_code maybe_code_for_pred_scalar(int, machine_mode); 0.340000
insn_code maybe_code_for_pred_dual_widen(rtx_code, rtx_code, machine_mode);
0.300000
insn_code maybe_code_for_pred_dual_widen_scalar(rtx_code, rtx_code,
machine_mode); 0.290000
Expanding all splitter functions (~8000) takes 214s, so roughly 40% of the
expansion time.
This we wouldn't get rid of even when not using insn helpers.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (17 preceding siblings ...)
2023-10-04 12:50 ` rdapp at gcc dot gnu.org
@ 2023-10-04 13:13 ` rguenth at gcc dot gnu.org
2023-10-04 13:21 ` rdapp at gcc dot gnu.org
` (15 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-10-04 13:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
Compiling insn-emit.ii on a x86_64 host with a 13.2 release compiler shows most
time is spent in inlining and CFG cleanup (the latter possibly in functions
with a very large number of conditionals).
For CCP it's interesting that most of the time is spent in ccp_finalize
(doing the substitute_and_fold step). That engine was made more and more
complicated (instead of getting rid of it ...).
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (18 preceding siblings ...)
2023-10-04 13:13 ` rguenth at gcc dot gnu.org
@ 2023-10-04 13:21 ` rdapp at gcc dot gnu.org
2023-10-04 13:56 ` rguenth at gcc dot gnu.org
` (14 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-10-04 13:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #20 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Mhm, why is your profile so different from mine? I'm also on an x86_64 host
with a 13.2.1 host compiler (Fedora).
Is it because of the preprocessed source? Or am I just reading the timing
report wrong?
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (19 preceding siblings ...)
2023-10-04 13:21 ` rdapp at gcc dot gnu.org
@ 2023-10-04 13:56 ` rguenth at gcc dot gnu.org
2023-10-04 14:38 ` rdapp at gcc dot gnu.org
` (13 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-10-04 13:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
I have a release checking GCC 13.2 based host compiler, profile ordered similar
to yours is the following where 'integration' is inlining
callgraph ipa passes : 22.94 ( 12%) 2.24 ( 12%) 25.19 ( 12%)
3307M ( 15%)
integration : 51.29 ( 27%) 5.56 ( 29%) 56.75 ( 27%)
12995M ( 59%)
tree CFG cleanup : 20.37 ( 11%) 2.05 ( 11%) 22.30 ( 11%)
219M ( 1%)
tree CCP : 21.72 ( 11%) 1.19 ( 6%) 22.85 ( 11%)
330M ( 2%)
integrated RA : 6.65 ( 4%) 0.62 ( 3%) 6.80 ( 3%)
876M ( 4%)
scheduling 2 : 5.21 ( 3%) 0.28 ( 1%) 5.45 ( 3%)
36M ( 0%)
TOTAL : 189.12 19.43 208.61
21939M
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (20 preceding siblings ...)
2023-10-04 13:56 ` rguenth at gcc dot gnu.org
@ 2023-10-04 14:38 ` rdapp at gcc dot gnu.org
2023-10-12 11:50 ` rdapp at gcc dot gnu.org
` (12 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-10-04 14:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #22 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Ah, then it's not that different, your machine is just faster ;)
callgraph ipa passes : 69.77 ( 11%) 5.97 ( 13%) 76.05 ( 12%)
2409M ( 10%)
integration : 91.95 ( 15%) 12.52 ( 27%) 105.93 ( 16%)
13408M ( 56%)
tree CFG cleanup : 76.98 ( 13%) 1.09 ( 2%) 78.01 ( 12%)
201M ( 1%)
tree STMT verifier : 66.62 ( 11%) 3.75 ( 8%) 68.31 ( 10%)
0 ( 0%)
integrated RA : 47.04 ( 8%) 1.00 ( 2%) 47.79 ( 7%)
879M ( 4%)
tree CCP : 44.31 ( 7%) 3.00 ( 6%) 48.39 ( 7%)
314M ( 1%)
tree SSA verifier : 31.40 ( 5%) 1.60 ( 3%) 32.25 ( 5%)
0 ( 0%)
CFG verifier : 14.93 ( 2%) 0.74 ( 2%) 16.53 ( 3%)
0 ( 0%)
callgraph verifier : 14.26 ( 2%) 1.07 ( 2%) 15.55 ( 2%)
0 ( 0%)
tree operand scan : 12.58 ( 2%) 3.73 ( 8%) 15.14 ( 2%)
1649M ( 7%)
verify RTL sharing : 11.70 ( 2%) 0.89 ( 2%) 13.31 ( 2%)
0 ( 0%)
TOTAL : 609.73 46.53 659.45
24127M
FWIW we are much faster with -fno-inline (somewhat expected but I didn't expect
a factor of 3):
callgraph ipa passes : 53.47 ( 27%) 5.84 ( 26%) 59.52 ( 26%)
2231M ( 26%)
tree STMT verifier : 19.67 ( 10%) 1.95 ( 9%) 21.47 ( 10%)
0 ( 0%)
tree SSA verifier : 11.80 ( 6%) 1.20 ( 5%) 13.32 ( 6%)
0 ( 0%)
integrated RA : 8.73 ( 4%) 0.72 ( 3%) 9.83 ( 4%)
898M ( 10%)
verify RTL sharing : 7.90 ( 4%) 0.69 ( 3%) 8.49 ( 4%)
0 ( 0%)
scheduling 2 : 7.32 ( 4%) 0.31 ( 1%) 7.90 ( 4%)
43M ( 1%)
tree PTA : 6.68 ( 3%) 0.69 ( 3%) 7.51 ( 3%)
71M ( 1%)
CFG verifier : 6.67 ( 3%) 0.81 ( 4%) 7.29 ( 3%)
0 ( 0%)
rest of compilation : 6.42 ( 3%) 0.93 ( 4%) 6.88 ( 3%)
89M ( 1%)
parser function body : 6.35 ( 3%) 2.13 ( 9%) 8.40 ( 4%)
903M ( 11%)
TOTAL : 201.12 22.90 225.17
8575M
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (21 preceding siblings ...)
2023-10-04 14:38 ` rdapp at gcc dot gnu.org
@ 2023-10-12 11:50 ` rdapp at gcc dot gnu.org
2023-10-13 1:39 ` juzhe.zhong at rivai dot ai
` (11 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-10-12 11:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #23 from Robin Dapp <rdapp at gcc dot gnu.org> ---
For the lack of a better idea (and time constraints as looking for compiler
bottlenecks is slow and tedious) I went with Kito's suggestion of splitting
insn-emit.cc
This reduces this part of the compilation with eight threads to 40s (from 10
min before). I evenly split the number of patterns into the 10 files but it
just so happens that the last file will receive all the problematical
maybe_code_for functions, so that file makes up for most of the 40s. The rest
usually takes 5-20s.
Doing bootstrapping tests now, going to post an initial patch once it's
"presentable".
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (22 preceding siblings ...)
2023-10-12 11:50 ` rdapp at gcc dot gnu.org
@ 2023-10-13 1:39 ` juzhe.zhong at rivai dot ai
2023-10-13 7:28 ` rdapp at gcc dot gnu.org
` (10 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-10-13 1:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
JuzheZhong <juzhe.zhong at rivai dot ai> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |juzhe.zhong at rivai dot ai
--- Comment #24 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Robin Dapp from comment #23)
> For the lack of a better idea (and time constraints as looking for compiler
> bottlenecks is slow and tedious) I went with Kito's suggestion of splitting
> insn-emit.cc
>
> This reduces this part of the compilation with eight threads to 40s (from 10
> min before). I evenly split the number of patterns into the 10 files but it
> just so happens that the last file will receive all the problematical
> maybe_code_for functions, so that file makes up for most of the 40s. The
> rest usually takes 5-20s.
>
> Doing bootstrapping tests now, going to post an initial patch once it's
> "presentable".
Hi, Robin. I believe your patch can solve the compile-time issue.
But I wonder whether it can fix memory consumption too ?
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (23 preceding siblings ...)
2023-10-13 1:39 ` juzhe.zhong at rivai dot ai
@ 2023-10-13 7:28 ` rdapp at gcc dot gnu.org
2023-10-13 8:01 ` rdapp at gcc dot gnu.org
` (9 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-10-13 7:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #25 from Robin Dapp <rdapp at gcc dot gnu.org> ---
At least here locally the maximum I saw was 1.4 GB of RES for insn-emit-10.cc.
That's still not ideal (especially when 8 or 10 of those files compile in
parallel) but at least no 8 GB for a single file anymore.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (24 preceding siblings ...)
2023-10-13 7:28 ` rdapp at gcc dot gnu.org
@ 2023-10-13 8:01 ` rdapp at gcc dot gnu.org
2023-10-13 8:04 ` rguenther at suse dot de
` (8 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-10-13 8:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #26 from Robin Dapp <rdapp at gcc dot gnu.org> ---
So insn-opinit.cc still takes 2-3 minutes to compile here, even though the file
is not gigantic.
With the same GCC 13.1 x86 host compiler I see:
phase opt and generate : 170.28 ( 99%) 0.75 ( 48%) 171.43 ( 99%)
561M ( 60%)
callgraph functions expansion : 35.04 ( 20%) 0.50 ( 32%) 35.65 (
21%) 356M ( 38%)
callgraph ipa passes : 135.02 ( 79%) 0.24 ( 15%) 135.55 ( 78%)
96M ( 10%)
tree Early VRP : 127.83 ( 75%) 0.00 ( 0%) 128.11 ( 74%)
3141k ( 0%)
Would need to re-check if this still happens with a GCC 14 host compiler. If
so, that might be worth investigating as it seems pretty localized.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (25 preceding siblings ...)
2023-10-13 8:01 ` rdapp at gcc dot gnu.org
@ 2023-10-13 8:04 ` rguenther at suse dot de
2023-10-31 12:35 ` cvs-commit at gcc dot gnu.org
` (7 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rguenther at suse dot de @ 2023-10-13 8:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 13 Oct 2023, rdapp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
>
> --- Comment #26 from Robin Dapp <rdapp at gcc dot gnu.org> ---
> So insn-opinit.cc still takes 2-3 minutes to compile here, even though the file
> is not gigantic.
> With the same GCC 13.1 x86 host compiler I see:
>
> phase opt and generate : 170.28 ( 99%) 0.75 ( 48%) 171.43 ( 99%)
> 561M ( 60%)
> callgraph functions expansion : 35.04 ( 20%) 0.50 ( 32%) 35.65 (
> 21%) 356M ( 38%)
> callgraph ipa passes : 135.02 ( 79%) 0.24 ( 15%) 135.55 ( 78%)
> 96M ( 10%)
> tree Early VRP : 127.83 ( 75%) 0.00 ( 0%) 128.11 ( 74%)
> 3141k ( 0%)
>
> Would need to re-check if this still happens with a GCC 14 host compiler. If
> so, that might be worth investigating as it seems pretty localized.
See PR111622
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (26 preceding siblings ...)
2023-10-13 8:04 ` rguenther at suse dot de
@ 2023-10-31 12:35 ` cvs-commit at gcc dot gnu.org
2023-11-01 2:24 ` juzhe.zhong at rivai dot ai
` (6 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-10-31 12:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #28 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Robin Dapp <rdapp@gcc.gnu.org>:
https://gcc.gnu.org/g:184378027e92f51e02d3649e0ca523f487fd2810
commit r14-5034-g184378027e92f51e02d3649e0ca523f487fd2810
Author: Robin Dapp <rdapp@ventanamicro.com>
Date: Thu Oct 12 11:23:26 2023 +0200
genemit: Split insn-emit.cc into several partitions.
On riscv insn-emit.cc has grown to over 1.2 mio lines of code and
compiling it takes considerable time.
Therefore, this patch adjust genemit to create several partitions
(insn-emit-1.cc to insn-emit-n.cc). The available patterns are
written to the given files in a sequential fashion.
Similar to match.pd a configure option --with-emitinsn-partitions=num
is introduced that makes the number of partition configurable.
gcc/ChangeLog:
PR bootstrap/84402
PR target/111600
* Makefile.in: Handle split insn-emit.cc.
* configure: Regenerate.
* configure.ac: Add --with-insnemit-partitions.
* genemit.cc (output_peephole2_scratches): Print to file instead
of stdout.
(print_code): Ditto.
(gen_rtx_scratch): Ditto.
(gen_exp): Ditto.
(gen_emit_seq): Ditto.
(emit_c_code): Ditto.
(gen_insn): Ditto.
(gen_expand): Ditto.
(gen_split): Ditto.
(output_add_clobbers): Ditto.
(output_added_clobbers_hard_reg_p): Ditto.
(print_overload_arguments): Ditto.
(print_overload_test): Ditto.
(handle_overloaded_code_for): Ditto.
(handle_overloaded_gen): Ditto.
(print_header): New function.
(handle_arg): New function.
(main): Split output into 10 files.
* gensupport.cc (count_patterns): New function.
* gensupport.h (count_patterns): Define.
* read-md.cc (md_reader::print_md_ptr_loc): Add file argument.
* read-md.h (class md_reader): Change definition.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (27 preceding siblings ...)
2023-10-31 12:35 ` cvs-commit at gcc dot gnu.org
@ 2023-11-01 2:24 ` juzhe.zhong at rivai dot ai
2023-11-02 9:31 ` rdapp at gcc dot gnu.org
` (5 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-11-01 2:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #29 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
insn-output.cc still has over 1.7 Million lines codes.
Is it possible split this file into 10 files too ?
It seems that it is also an issue for compile time ?
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (28 preceding siblings ...)
2023-11-01 2:24 ` juzhe.zhong at rivai dot ai
@ 2023-11-02 9:31 ` rdapp at gcc dot gnu.org
2023-11-06 18:15 ` schwab@linux-m68k.org
` (4 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rdapp at gcc dot gnu.org @ 2023-11-02 9:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #30 from Robin Dapp <rdapp at gcc dot gnu.org> ---
On my machine it is not nearly as bad as insn-emit.cc. What dominates for me
with a GCC 13 host compiler is the already fixed insn-opinit problem.
How long does it take for you (maybe in % of the total build)? In principle
splitting it should be similar to insn-emit and mostly mechanical.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (29 preceding siblings ...)
2023-11-02 9:31 ` rdapp at gcc dot gnu.org
@ 2023-11-06 18:15 ` schwab@linux-m68k.org
2023-11-06 22:07 ` juzhe.zhong at rivai dot ai
` (3 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: schwab@linux-m68k.org @ 2023-11-06 18:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #31 from Andreas Schwab <schwab@linux-m68k.org> ---
For the first time the bootstrap time has been reduced, from 192543 (20231028)
to 141231 (20231103), -26,6%.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (30 preceding siblings ...)
2023-11-06 18:15 ` schwab@linux-m68k.org
@ 2023-11-06 22:07 ` juzhe.zhong at rivai dot ai
2024-03-04 4:31 ` law at gcc dot gnu.org
` (2 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: juzhe.zhong at rivai dot ai @ 2023-11-06 22:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #32 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
26% time reduction seems not enough.
Maybe we still need to optimize MD patterns to fix this issue ?
But I have no idea to optimize it since I already tried my best to reduce
them.
According to RVV intrinsic doc:
https://github.com/riscv-non-isa/rvv-intrinsic-doc
we have these 6 types variant intrinsics:
__vop
__vop_tu
__vop_mu
__vop_tum
__vop_tumu
__vop_m
I have fused them into same pattern (which makes the pattern so complicated) to
avoid explosion of MD patterns (otherwise, it will explode 6 times if we
dedicate each type intrinsic one MD pattern).
But seems it's still an issue. And I have no idea how to reduce them.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (31 preceding siblings ...)
2023-11-06 22:07 ` juzhe.zhong at rivai dot ai
@ 2024-03-04 4:31 ` law at gcc dot gnu.org
2024-04-30 8:26 ` [Bug target/111600] [14/15 " cvs-commit at gcc dot gnu.org
2024-05-07 7:42 ` rguenth at gcc dot gnu.org
34 siblings, 0 replies; 36+ messages in thread
From: law at gcc dot gnu.org @ 2024-03-04 4:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14/15 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (32 preceding siblings ...)
2024-03-04 4:31 ` law at gcc dot gnu.org
@ 2024-04-30 8:26 ` cvs-commit at gcc dot gnu.org
2024-05-07 7:42 ` rguenth at gcc dot gnu.org
34 siblings, 0 replies; 36+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-04-30 8:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #33 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:440a612dbadfae5887ec7c9b3ab2fca88b065366
commit r13-8662-g440a612dbadfae5887ec7c9b3ab2fca88b065366
Author: Richard Biener <rguenther@suse.de>
Date: Thu Sep 28 11:51:30 2023 +0200
target/111600 - avoid deep recursion in access diagnostics
pass_waccess::check_dangling_stores uses recursion to traverse the CFG.
The following changes this to use a heap allocated worklist to avoid
blowing the stack.
Instead of using a better iteration order it tries hard to preserve
the current iteration order to avoid new false positives to pop up
since the set of stores we keep track isn't properly modeling flow,
so what is diagnosed and what not is quite random. We are also
lacking the ideal RPO compute on the inverted graph that would just
ignore reverse unreachable code (as the current iteration scheme does).
PR target/111600
* gimple-ssa-warn-access.cc (pass_waccess::check_dangling_stores):
Use a heap allocated worklist for CFG traversal instead of
recursion.
(cherry picked from commit f194c684a28a5d449bd034a2c604d04ba465e4fe)
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug target/111600] [14/15 Regression] RISC-V bootstrap time regression
2023-09-26 13:35 [Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression schwab@linux-m68k.org
` (33 preceding siblings ...)
2024-04-30 8:26 ` [Bug target/111600] [14/15 " cvs-commit at gcc dot gnu.org
@ 2024-05-07 7:42 ` rguenth at gcc dot gnu.org
34 siblings, 0 replies; 36+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-07 7:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|14.0 |14.2
--- Comment #34 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 14.1 is being released, retargeting bugs to GCC 14.2.
^ permalink raw reply [flat|nested] 36+ messages in thread