[Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression

[Bug target/111600] New: [14.0 regression] RISC-V bootstrap time regression

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600

            Bug ID: 111600
           Summary: [14.0 regression] RISC-V bootstrap time regression
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: schwab@linux-m68k.org
  Target Milestone: ---
            Target: riscv*-*-*

Between 20230915 and 20230922 the total bootstrap time (all languages enabled)
has increased from 127309 to 156925 seconds.

Bootstrap times for weekly builds of the last two months:

20230714        99353
20230722        95286   +4.3%
20230728        96453   +1.2%
20230804        97106   +0.7%
20230811        107889  +11.1%
20230818        108573  +0.6%
20230825        110850  +2.1%
20230901        111338  +0.4%
20230908        120820  +8.5%
20230915        127309  +5.4%
20230922        156925  +23.3%

Compiling dwarf2out.cc (preprocessed from the 20230714 tree) with the stage3
compilers, -O2 -g:

20230714        417.455
20230722        417.031
20230728        416.201
20230804        419.312
20230811        418.617
20230818        419.281
20230825        419.950
20230901        421.329
20230908        425.063
20230915        426.305
20230922        430.378

[Bug target/111600] [14.0 regression] RISC-V bootstrap time regression

[pinskia at gcc dot gnu.org]

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 ...

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rguenth at gcc dot gnu.org]

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?

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[schwab@linux-m68k.org]

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%

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[schwab@linux-m68k.org]

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

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rguenth at gcc dot gnu.org]

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).

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[schwab@linux-m68k.org]

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

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[palmer at gcc dot gnu.org]

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?

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600

--- Comment #8 from Andreas Schwab <schwab@linux-m68k.org> ---
Native on HiFive Unleashed.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[schwab@linux-m68k.org]

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.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rguenth at gcc dot gnu.org]

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).

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[cvs-commit at gcc dot gnu.org]

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.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rdapp at gcc dot gnu.org]

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.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[kito at gcc dot gnu.org]

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?

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[kito at gcc dot gnu.org]

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

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rguenth at gcc dot gnu.org]

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).

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rdapp at gcc dot gnu.org]

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.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rguenther at suse dot de]

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.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rdapp at gcc dot gnu.org]

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.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rguenth at gcc dot gnu.org]

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 ...).

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rdapp at gcc dot gnu.org]

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?

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rguenth at gcc dot gnu.org]

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

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rdapp at gcc dot gnu.org]

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

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rdapp at gcc dot gnu.org]

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".

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[juzhe.zhong at rivai dot ai]

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 ?

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rdapp at gcc dot gnu.org]

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.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rdapp at gcc dot gnu.org]

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.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rguenther at suse dot de]

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

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[cvs-commit at gcc dot gnu.org]

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.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[juzhe.zhong at rivai dot ai]

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 ?

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[rdapp at gcc dot gnu.org]

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.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[schwab@linux-m68k.org]

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%.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[juzhe.zhong at rivai dot ai]

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.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

[law at gcc dot gnu.org]

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

[Bug target/111600] [14/15 Regression] RISC-V bootstrap time regression

[cvs-commit at gcc dot gnu.org]

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)

[Bug target/111600] [14/15 Regression] RISC-V bootstrap time regression

[rguenth at gcc dot gnu.org]

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.