[Bug middle-end/27733] New: Large compile time regression

[Bug middle-end/27733] New: Large compile time regression

[danglin at gcc dot gnu dot org]

Relative to gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3),
gcc version 4.1.1 20060511 (prerelease) (Debian 4.1.0-4) and also my own
build of 4.2 exhibit a large increase in compile on the attached file.
On my c3k, the time goes from ~ 5 seconds to 49 minutes.

The compile command used is:

/usr/bin/hppa64-linux-gnu-gcc-4.1 -nostdinc -v alloc.i -mno-space-regs
-mfast-indirect-calls -mdisable-fpregs -march=2.0 -mschedule=8000 -O2 -Wall
-Wundef -Wstrict-prototypes -Wno-trigraphs -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-aliasing -fno-common -fomit-frame-pointer
-ffunction-sections -S


-- 
           Summary: Large compile time regression
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] Large compile time regression

[danglin at gcc dot gnu dot org]

------- Comment #1 from danglin at gcc dot gnu dot org  2006-05-22 20:38 -------
Created an attachment (id=11495)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11495&action=view)
Preprocessed source.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] Large compile time regression

[danglin at gcc dot gnu dot org]

------- Comment #2 from danglin at gcc dot gnu dot org  2006-05-22 22:26 -------
Execution times (seconds)
 callgraph construction:   0.06 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall
   142 kB ( 1%) ggc
 callgraph optimization:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
    16 kB ( 0%) ggc
 ipa reference         :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
     4 kB ( 0%) ggc
 ipa pure const        :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
     0 kB ( 0%) ggc
 ipa type escape       :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall
     0 kB ( 0%) ggc
 cfg cleanup           :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall
    17 kB ( 0%) ggc
 trivially dead code   :   0.06 ( 0%) usr   0.01 ( 0%) sys   0.03 ( 0%) wall
     0 kB ( 0%) ggc
 life analysis         :   0.16 ( 0%) usr   0.00 ( 0%) sys   0.18 ( 0%) wall
    84 kB ( 1%) ggc
 life info update      :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall
    10 kB ( 0%) ggc
 alias analysis        :   0.08 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall
   225 kB ( 1%) ggc
 register scan         :   0.06 ( 0%) usr   0.01 ( 0%) sys   0.07 ( 0%) wall
     1 kB ( 0%) ggc
 rebuild jump labels   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
     0 kB ( 0%) ggc
 preprocessing         :   0.37 ( 0%) usr   0.45 (11%) sys   1.99 ( 0%) wall
  1495 kB (10%) ggc
 lexical analysis      :   0.07 ( 0%) usr   0.89 (21%) sys   1.00 ( 0%) wall
     0 kB ( 0%) ggc
 parser                :   0.55 ( 0%) usr   0.45 (11%) sys   0.88 ( 0%) wall
  4186 kB (27%) ggc
 integration           :   0.08 ( 0%) usr   0.02 ( 0%) sys   0.11 ( 0%) wall
  1175 kB ( 8%) ggc
 tree gimplify         :   0.14 ( 0%) usr   0.00 ( 0%) sys   0.23 ( 0%) wall
   752 kB ( 5%) ggc
 tree eh               :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
     0 kB ( 0%) ggc
 tree CFG construction :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall
   412 kB ( 3%) ggc
 tree CFG cleanup      :   0.06 ( 0%) usr   0.01 ( 0%) sys   0.10 ( 0%) wall
    10 kB ( 0%) ggc
 tree VRP              :   0.06 ( 0%) usr   0.02 ( 0%) sys   0.10 ( 0%) wall
   130 kB ( 1%) ggc
 tree copy propagation :   0.07 ( 0%) usr   0.01 ( 0%) sys   0.04 ( 0%) wall
    90 kB ( 1%) ggc
 tree find ref. vars   :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
   152 kB ( 1%) ggc
 tree PTA              :   0.21 ( 0%) usr   0.00 ( 0%) sys   0.14 ( 0%) wall
   260 kB ( 2%) ggc
 tree alias analysis   :   0.02 ( 0%) usr   0.03 ( 1%) sys   0.08 ( 0%) wall
   130 kB ( 1%) ggc
 tree PHI insertion    :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
    38 kB ( 0%) ggc
 tree SSA rewrite      :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall
   228 kB ( 1%) ggc
 tree SSA other        :   0.02 ( 0%) usr   0.01 ( 0%) sys   0.04 ( 0%) wall
     0 kB ( 0%) ggc
 tree SSA incremental  :   0.04 ( 0%) usr   0.02 ( 0%) sys   0.06 ( 0%) wall
    47 kB ( 0%) ggc
 tree operand scan     :   0.20 ( 0%) usr   0.12 ( 3%) sys   0.25 ( 0%) wall
   209 kB ( 1%) ggc
 dominator optimization:   0.13 ( 0%) usr   0.01 ( 0%) sys   0.15 ( 0%) wall
   313 kB ( 2%) ggc
 tree SRA              :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
     0 kB ( 0%) ggc
 tree STORE-CCP        :   0.01 ( 0%) usr   0.01 ( 0%) sys   0.01 ( 0%) wall
    19 kB ( 0%) ggc
 tree CCP              :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall
    20 kB ( 0%) ggc
 tree PRE              :   0.08 ( 0%) usr   0.00 ( 0%) sys   0.11 ( 0%) wall
   216 kB ( 1%) ggc
 tree FRE              :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall
   145 kB ( 1%) ggc
 tree code sinking     :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
     1 kB ( 0%) ggc
 tree forward propagate:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
    17 kB ( 0%) ggc
 tree conservative DCE :   0.01 ( 0%) usr   0.01 ( 0%) sys   0.01 ( 0%) wall
     0 kB ( 0%) ggc
 tree aggressive DCE   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
     0 kB ( 0%) ggc
 tree DSE              :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
     7 kB ( 0%) ggc
 tree loop bounds      :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall
    34 kB ( 0%) ggc
 tree canonical iv     :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
    23 kB ( 0%) ggc
 complete unrolling    :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
    21 kB ( 0%) ggc
 tree iv optimization  :   0.11 ( 0%) usr   0.02 ( 0%) sys   0.12 ( 0%) wall
   360 kB ( 2%) ggc
 tree copy headers     :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
    86 kB ( 1%) ggc
 tree SSA uncprop      :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
     0 kB ( 0%) ggc
 tree SSA to normal    :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall
   141 kB ( 1%) ggc
 tree NRV optimization :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
     0 kB ( 0%) ggc
 dominance frontiers   :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
     0 kB ( 0%) ggc
 expand                :5242.96 (100%) usr   2.06 (49%) sys5333.55 (100%) wall
   1058 kB ( 7%) ggc
 jump                  :   0.00 ( 0%) usr   0.01 ( 0%) sys   0.00 ( 0%) wall
     4 kB ( 0%) ggc
 CSE                   :   0.22 ( 0%) usr   0.00 ( 0%) sys   0.26 ( 0%) wall
    57 kB ( 0%) ggc
 loop analysis         :   0.08 ( 0%) usr   0.01 ( 0%) sys   0.10 ( 0%) wall
   209 kB ( 1%) ggc
 global CSE            :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
     0 kB ( 0%) ggc
 CPROP 1               :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall
    54 kB ( 0%) ggc
 PRE                   :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
    11 kB ( 0%) ggc
 CPROP 2               :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall
    50 kB ( 0%) ggc
 bypass jumps          :   0.05 ( 0%) usr   0.01 ( 0%) sys   0.05 ( 0%) wall
    47 kB ( 0%) ggc
 CSE 2                 :   0.17 ( 0%) usr   0.01 ( 0%) sys   0.17 ( 0%) wall
    30 kB ( 0%) ggc
 branch prediction     :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall
    45 kB ( 0%) ggc
 combiner              :   0.23 ( 0%) usr   0.01 ( 0%) sys   0.20 ( 0%) wall
   261 kB ( 2%) ggc
 if-conversion         :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
     9 kB ( 0%) ggc
 regmove               :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall
     3 kB ( 0%) ggc
 scheduling            :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.12 ( 0%) wall
   302 kB ( 2%) ggc
 local alloc           :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall
    73 kB ( 0%) ggc
 global alloc          :   0.15 ( 0%) usr   0.00 ( 0%) sys   0.13 ( 0%) wall
   153 kB ( 1%) ggc
 reload CSE regs       :   0.06 ( 0%) usr   0.01 ( 0%) sys   0.09 ( 0%) wall
   134 kB ( 1%) ggc
 flow 2                :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
   150 kB ( 1%) ggc
 if-conversion 2       :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
     0 kB ( 0%) ggc
 peephole 2            :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
     3 kB ( 0%) ggc
 rename registers      :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall
     1 kB ( 0%) ggc
 scheduling 2          :   0.14 ( 0%) usr   0.01 ( 0%) sys   0.15 ( 0%) wall
   177 kB ( 1%) ggc
 delay branch sched    :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall
   250 kB ( 2%) ggc
 reorder blocks        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall
    50 kB ( 0%) ggc
 shorten branches      :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
     0 kB ( 0%) ggc
 final                 :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%) wall
    82 kB ( 1%) ggc
 symout                :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
     0 kB ( 0%) ggc
 TOTAL                 :5247.66             4.24          5342.10
 15337 kB

These are the pass times in the report sent to me.  As can be seen, all
the time is spent in expand.

It appears the problem is the function free_area_init_node.  I see the
following
backtrace:

Assembling functions:
 zone_watermark_ok nr_free_zone_pages read_page_state_offset
__mod_page_state_offset mod_page_state_offset __get_zone_counts
memmap_init_zone zone_init_free_lists zonetable_add frag_stop vmstat_next
page_alloc_init calculate_totalreserve_pages setup_per_zone_lowmem_reserve
frag_next frag_start {GC 6427k -> 3960k} get_zone_counts vmstat_show
vmstat_stop zoneinfo_show lowmem_reserve_ratio_sysctl_handler
percpu_pagelist_fraction_sysctl_handler setup_per_zone_pages_min nr_free_pages
min_free_kbytes_sysctl_handler free_area_init_node
Program received signal SIGINT, Interrupt.
0x004eec44 in $$divU ()
(gdb) bt
#0  0x004eec44 in $$divU ()
#1  0x004f11fc in __umoddi3 ()
#2  0x00216490 in synth_mult (alg_out=0xc0363c60, t=<value optimized out>,
    cost_limit=0xc0363bc8, mode=DImode) at ../../gcc/gcc/expmed.c:2717
#3  0x00216320 in synth_mult (alg_out=0xc0363860, t=<value optimized out>,
    cost_limit=0xc03637c8, mode=DImode) at ../../gcc/gcc/expmed.c:2625
#4  0x00215e6c in synth_mult (alg_out=0xc0363460, t=<value optimized out>,
    cost_limit=0xc03633c8, mode=DImode) at ../../gcc/gcc/expmed.c:2584
#5  0x00215f30 in synth_mult (alg_out=0xc0363060, t=<value optimized out>,
    cost_limit=0xc0362fc8, mode=DImode) at ../../gcc/gcc/expmed.c:2645
#6  0x00216158 in synth_mult (alg_out=0xc0362c60, t=<value optimized out>,
    cost_limit=0xc0362bc8, mode=DImode) at ../../gcc/gcc/expmed.c:2795
#7  0x00216570 in synth_mult (alg_out=0xc0362860, t=<value optimized out>,
    cost_limit=0xc03627c8, mode=DImode) at ../../gcc/gcc/expmed.c:2698
#8  0x00216838 in synth_mult (alg_out=0xc0362460, t=<value optimized out>,
    cost_limit=0xc03623c8, mode=DImode) at ../../gcc/gcc/expmed.c:2770
#9  0x00216838 in synth_mult (alg_out=0xc0362060, t=<value optimized out>,
    cost_limit=0xc0361fc8, mode=DImode) at ../../gcc/gcc/expmed.c:2770
#10 0x00216838 in synth_mult (alg_out=0xc0361c60, t=<value optimized out>,
    cost_limit=0xc0361bc8, mode=DImode) at ../../gcc/gcc/expmed.c:2770
#11 0x00215e6c in synth_mult (alg_out=0xc0361860, t=<value optimized out>,
    cost_limit=0xc03617c8, mode=DImode) at ../../gcc/gcc/expmed.c:2584
#12 0x00216570 in synth_mult (alg_out=0xc0361460, t=<value optimized out>,
---Type <return> to continue, or q <return> to quit---
    cost_limit=0xc03613c8, mode=DImode) at ../../gcc/gcc/expmed.c:2698
#13 0x00215f30 in synth_mult (alg_out=0xc0361060, t=<value optimized out>,
    cost_limit=0xc0360fc8, mode=DImode) at ../../gcc/gcc/expmed.c:2645
#14 0x00216158 in synth_mult (alg_out=0xc0360c60, t=<value optimized out>,
    cost_limit=0xc0360bc8, mode=DImode) at ../../gcc/gcc/expmed.c:2795
#15 0x00215e6c in synth_mult (alg_out=0xc0360860, t=<value optimized out>,
    cost_limit=0xc03607c8, mode=DImode) at ../../gcc/gcc/expmed.c:2584
#16 0x00216320 in synth_mult (alg_out=0xc03605e0, t=<value optimized out>,
    cost_limit=0xc03603c8, mode=DImode) at ../../gcc/gcc/expmed.c:2625
#17 0x00216838 in synth_mult (alg_out=0xc0360024, t=<value optimized out>,
    cost_limit=0xc0360208, mode=DImode) at ../../gcc/gcc/expmed.c:2770
#18 0x00216a30 in choose_mult_variant (mode=DImode, val=-1069376468041133427,
    alg=0xc0360024, variant=0xc0360008, mult_cost=80)
    at ../../gcc/gcc/expmed.c:2887
#19 0x002174f8 in expand_mult (mode=DImode, op0=<value optimized out>,
    op1=0x405cc810, target=0x0, unsignedp=0) at ../../gcc/gcc/expmed.c:3188
#20 0x00151904 in multiply_by_cost (cst=-1069376468041133427, mode=DImode)
    at ../../gcc/gcc/tree-ssa-loop-ivopts.c:3180
#21 0x001552a4 in get_computation_cost (data=<value optimized out>,
    use=<value optimized out>, cand=<value optimized out>,
    address_p=<value optimized out>, depends_on=0x0)
    at ../../gcc/gcc/tree-ssa-loop-ivopts.c:3314
#22 0x0015750c in determine_use_iv_cost (data=0xc035fc88, use=0xffff,
---Type <return> to continue, or q <return> to quit---
    cand=0x6bf020) at ../../gcc/gcc/tree-ssa-loop-ivopts.c:3871
#23 0x0015ae98 in determine_use_iv_costs (data=0xc035fc88)
    at ../../gcc/gcc/tree-ssa-loop-ivopts.c:4108
#24 0x0015be34 in tree_ssa_iv_optimize_loop (data=0xc035fc88,
    loop=<value optimized out>) at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5765
#25 0x0015c730 in tree_ssa_iv_optimize (loops=0x672568)
    at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5817
#26 0x00129d34 in tree_ssa_loop_ivopts () at ../../gcc/gcc/tree-ssa-loop.c:457
#27 0x00396fc4 in execute_one_pass (pass=0x59ce18)
    at ../../gcc/gcc/passes.c:864
#28 0x00397178 in execute_pass_list (pass=0x59ce18)
    at ../../gcc/gcc/passes.c:911
#29 0x0039718c in execute_pass_list (pass=0x59d088)
    at ../../gcc/gcc/passes.c:912
#30 0x0039718c in execute_pass_list (pass=0x59ca04)
    at ../../gcc/gcc/passes.c:912
#31 0x000bbe34 in tree_rest_of_compilation (fndecl=0x40461100)
    at ../../gcc/gcc/tree-optimize.c:418
#32 0x00030dcc in c_expand_body (fndecl=0x6) at ../../gcc/gcc/c-decl.c:6723
#33 0x003df510 in cgraph_expand_function (node=0x400b7180)
    at ../../gcc/gcc/cgraphunit.c:1108
#34 0x003e0bc0 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1173
#35 0x00033c1c in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7838
---Type <return> to continue, or q <return> to quit---
#36 0x0035c2e0 in toplev_main (argc=<value optimized out>,
    argv=<value optimized out>) at ../../gcc/gcc/toplev.c:1012
#37 0x4072d6d8 in __libc_start_main () from /lib/libc.so.6
#38 0x0001be98 in _start () at ../sysdeps/hppa/elf/start.S:84


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-05-23 02:29 -------
This is not the first time multiply expand is taking this long.

There was another bug about something like this but for alpha.

It would be interesting which multiply is getting messed up by expand.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Large compile time          |[4.1/4.2 Regression] Large
                   |regression                  |compile time regression
   Target Milestone|---                         |4.1.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2006-05-23 13:49 -------
Subject: Re:  [4.1/4.2 Regression] Large compile time regression

> This is not the first time multiply expand is taking this long.
> 
> There was another bug about something like this but for alpha.

Note that this is for a 32 to 64-bit hppa cross.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[mmitchel at gcc dot gnu dot org]

------- Comment #5 from mmitchel at gcc dot gnu dot org  2006-05-25 02:35 -------
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.1                       |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[sje at cup dot hp dot com]

------- Comment #6 from sje at cup dot hp dot com  2006-06-06 19:52 -------
Created an attachment (id=11612)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11612&action=view)
Cut down test case

Here is a cutdown test case.  I reproduced the problem on hppa64-hp-hpux11.11
with this cutdown testcase.  When compiling with -O2 it compiles quickly (less
than 1 second) when compiled with -O2 -mdisable-fpregs it took 17 minutes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[sje at cup dot hp dot com]

------- Comment #7 from sje at cup dot hp dot com  2006-06-06 20:48 -------
This seems to be identical to PR 23971 on alpha.  The test case for that PR:

unsigned long long f(unsigned long long x) { return x *
5445825408751490200ULL;}

I changed long to 'long long' to make it 64 bits on hppa1.1 and hppa64.  It
compiles fine on hppa1.1-*-* but takes forever on hppa64-*-* with "-O2
-mdisable-fpregs".

PR 23971 is closed as fixed, I don't know if alpha is having this problem
anymore or not.


-- 

sje at cup dot hp dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-06-06 20:48:12
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[falk at debian dot org]

------- Comment #8 from falk at debian dot org  2006-06-06 21:04 -------
(In reply to comment #7)

> PR 23971 is closed as fixed, I don't know if alpha is having this problem
> anymore or not.

It takes 3.39s now, which while much faster than it used to be is still
ridiculously slow (with 1 as constant, it takes 0.06s).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[sje at cup dot hp dot com]

------- Comment #9 from sje at cup dot hp dot com  2006-06-06 21:30 -------
3.39s is not ridiculously slow, 15+ minutes is ridiculously slow. 1.64 seconds
using the constant 1.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[bonzini at gnu dot org]

------- Comment #10 from bonzini at gnu dot org  2006-06-08 12:08 -------
Reduced testcase:

long foo(long zz)  
{
 return zz * 15238614669586151335;
}

takes "ridiculously long" with -O2 -mdisable-fpregs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[bonzini at gnu dot org]

------- Comment #11 from bonzini at gnu dot org  2006-06-08 12:24 -------
OUCH! The number is stored as a unsigned int in the cache, which means that
numbers > 2^32 never hit the cache!

Besides that, it's wise to enlarge the cache for 64-bit hosts, because there
every EXACT_DIV_EXPR will call synth_mult with a very large multiplier.  Time
for a -O0 compiler on the reduced testcase is down to 0.3s for 2069 cache
entries, and 0.8s for 1031 cache entries.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[bonzini at gnu dot org]

------- Comment #12 from bonzini at gnu dot org  2006-06-08 12:26 -------
Created an attachment (id=11634)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11634&action=view)
proposed patch


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[sje at cup dot hp dot com]

------- Comment #13 from sje at cup dot hp dot com  2006-06-08 15:11 -------
The proposed patch does fix the compilation time problem on hppa64-hp-hpux11.11
but I am confused about how the cache works.  Without the patch, the compile
takes 15 to 20 minutes but I do wind up generating a sequence of instructions
instead of a call to __divdi3.  With the patch, I get a very fast compilation,
but I also get a call to __divdi3 instead of the code sequence.  Why does
caching results change the behaviour?  Caches (in general) should speed things
up by saving previous/intermediate results, but shouldn't change the ultimate
answer.  This seems to be doing something different.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[bonzini at gnu dot org]

------- Comment #14 from bonzini at gnu dot org  2006-06-08 15:37 -------
Well, it shouldn't.  My guess could be that we are hitting the case where the
logic is flawed.  The we fill the cache with the algorithm for say 0x100000085
(but then we only write 0x84 in the cache), and then use it for 0x85.  The
synth_mult logic then could be resilient enough to not generate wrong code but
just code with wrong cost measures.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[bonzini at gcc dot gnu dot org]

------- Comment #15 from bonzini at gnu dot org  2006-06-08 15:40 -------
Subject: Bug 27733

Author: bonzini
Date: Thu Jun  8 15:40:48 2006
New Revision: 114488

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114488
Log:
2006-06-08  Paolo Bonzini  <bonzini@gnu.org>

        PR middle-end/27733
        * expmed.c (struct alg_hash_entry): Fix type of field T
        to match synth_mult argument.
        (NUM_ALG_HASH_ENTRIES): Make it bigger for 64-bit HOST_WIDE_INT.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expmed.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression

[sje at cup dot hp dot com]

------- Comment #16 from sje at cup dot hp dot com  2006-06-08 15:50 -------
Bizarre, I could swear that when I first tried your fix I got a call to
__muldi3, but I just updated expmed.c, reran the test case and I got the same
inlined sequence that I got before the patch.  I think in the first case I had
reduced the cost of MULT on hppa64 and that is why I got the __divdi3 call.  I
put the MULT cost back to where it was and now I get the inline sequence.

In short, the compilation now takes 30 seconds instead of 15 minutes and I get
the same code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1 Regression] Large compile time regression

[soete dot joel at tiscali dot be]

------- Comment #17 from soete dot joel at tiscali dot be  2006-06-11 13:56 -------
Yes, it does the drill: 
I back port this patch against debian gcc-4.1 stock sources (gcc version 4.1.2
20060604 (prerelease) (Debian 4.1.1-2)) and got this excellent improvement of
the real case (kernel parisc linux page_alloc.c)
# time sh ../TstPageAlloc
+ hppa64-linux-gnu-gcc-4.1 -Wp,-MD,mm/.page_alloc.o.d -nostdinc -isystem
/usr/li
b/gcc/hppa64-linux-gnu/4.1.2/include -D__KERNEL__ -Iinclude -Iinclude2
-I/CAD/li
nux-2.6.17-rc5-pa3/include -include include/linux/autoconf.h
-I/CAD/linux-2.6.17
-rc5-pa3/mm -Imm -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-al
iasing -fno-common -O2 -fomit-frame-pointer -pipe -mno-space-regs
-mfast-indirec
t-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000
-Wdeclar
ation-after-statement -Wno-pointer-sign '-DKBUILD_STR(s)=#s'
'-DKBUILD_BASENAME=
KBUILD_STR(page_alloc)' '-DKBUILD_MODNAME=KBUILD_STR(page_alloc)' -c -o
mm/.tmp_
page_alloc.o /CAD/linux-2.6.17-rc5-pa3/mm/page_alloc.c

with the debian stock 64bit xcompiler:

real    92m41.950s
user    88m4.628s
sys     0m2.520s

with patch applied:

real    2m32.845s
user    2m24.835s
sys     0m0.229s

Thanks a lot,
    J.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1 Regression] Large compile time regression

[bonzini at gcc dot gnu dot org]

------- Comment #18 from bonzini at gnu dot org  2006-06-13 13:05 -------
Subject: Bug 27733

Author: bonzini
Date: Tue Jun 13 13:05:39 2006
New Revision: 114610

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114610
Log:
2006-06-13  Paolo Bonzini  <bonzini@gnu.org>

        PR middle-end/27733
        * expmed.c (struct alg_hash_entry): Fix type of field T
        to match synth_mult argument.
        (NUM_ALG_HASH_ENTRIES): Make it bigger for 64-bit HOST_WIDE_INT.

Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/expmed.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1 Regression] Large compile time regression

[bonzini at gnu dot org]

------- Comment #19 from bonzini at gnu dot org  2006-06-13 13:06 -------
Fixed, but we may want the patch on 4.0 too.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|4.1.0                       |4.1.1
      Known to work|4.0.4 4.2.0                 |4.0.4 4.1.2 4.2.0
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733

[Bug middle-end/27733] [4.1 Regression] Large compile time regression

[soete dot joel at tiscali dot be]

------- Comment #20 from soete dot joel at tiscali dot be  2006-06-13 15:43 -------
(In reply to comment #19)
> Fixed, but we may want the patch on 4.0 too.
> 
Curious I didn't notice this pb gcc-4.0?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733