* [Bug middle-end/27733] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
@ 2006-05-22 20:38 ` danglin at gcc dot gnu dot org
2006-05-22 22:26 ` danglin at gcc dot gnu dot org
` (19 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: danglin at gcc dot gnu dot org @ 2006-05-22 20:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
2006-05-22 20:38 ` [Bug middle-end/27733] " danglin at gcc dot gnu dot org
@ 2006-05-22 22:26 ` danglin at gcc dot gnu dot org
2006-05-23 2:30 ` [Bug middle-end/27733] [4.1/4.2 Regression] " pinskia at gcc dot gnu dot org
` (18 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: danglin at gcc dot gnu dot org @ 2006-05-22 22:26 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
2006-05-22 20:38 ` [Bug middle-end/27733] " danglin at gcc dot gnu dot org
2006-05-22 22:26 ` danglin at gcc dot gnu dot org
@ 2006-05-23 2:30 ` pinskia at gcc dot gnu dot org
2006-05-23 13:50 ` dave at hiauly1 dot hia dot nrc dot ca
` (17 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-05-23 2:30 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (2 preceding siblings ...)
2006-05-23 2:30 ` [Bug middle-end/27733] [4.1/4.2 Regression] " pinskia at gcc dot gnu dot org
@ 2006-05-23 13:50 ` dave at hiauly1 dot hia dot nrc dot ca
2006-05-25 2:42 ` mmitchel at gcc dot gnu dot org
` (16 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2006-05-23 13:50 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (3 preceding siblings ...)
2006-05-23 13:50 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2006-05-25 2:42 ` mmitchel at gcc dot gnu dot org
2006-06-04 19:22 ` mmitchel at gcc dot gnu dot org
` (15 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2006-05-25 2:42 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (4 preceding siblings ...)
2006-05-25 2:42 ` mmitchel at gcc dot gnu dot org
@ 2006-06-04 19:22 ` mmitchel at gcc dot gnu dot org
2006-06-06 20:08 ` sje at cup dot hp dot com
` (14 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2006-06-04 19:22 UTC (permalink / raw)
To: gcc-bugs
--
mmitchel at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (5 preceding siblings ...)
2006-06-04 19:22 ` mmitchel at gcc dot gnu dot org
@ 2006-06-06 20:08 ` sje at cup dot hp dot com
2006-06-06 20:48 ` sje at cup dot hp dot com
` (13 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: sje at cup dot hp dot com @ 2006-06-06 20:08 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (6 preceding siblings ...)
2006-06-06 20:08 ` sje at cup dot hp dot com
@ 2006-06-06 20:48 ` sje at cup dot hp dot com
2006-06-06 21:05 ` falk at debian dot org
` (12 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: sje at cup dot hp dot com @ 2006-06-06 20:48 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (7 preceding siblings ...)
2006-06-06 20:48 ` sje at cup dot hp dot com
@ 2006-06-06 21:05 ` falk at debian dot org
2006-06-06 21:32 ` sje at cup dot hp dot com
` (11 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: falk at debian dot org @ 2006-06-06 21:05 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (8 preceding siblings ...)
2006-06-06 21:05 ` falk at debian dot org
@ 2006-06-06 21:32 ` sje at cup dot hp dot com
2006-06-08 12:24 ` bonzini at gnu dot org
` (10 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: sje at cup dot hp dot com @ 2006-06-06 21:32 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (9 preceding siblings ...)
2006-06-06 21:32 ` sje at cup dot hp dot com
@ 2006-06-08 12:24 ` bonzini at gnu dot org
2006-06-08 12:27 ` bonzini at gnu dot org
` (9 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: bonzini at gnu dot org @ 2006-06-08 12:24 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (10 preceding siblings ...)
2006-06-08 12:24 ` bonzini at gnu dot org
@ 2006-06-08 12:27 ` bonzini at gnu dot org
2006-06-08 13:04 ` bonzini at gnu dot org
` (8 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: bonzini at gnu dot org @ 2006-06-08 12:27 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (11 preceding siblings ...)
2006-06-08 12:27 ` bonzini at gnu dot org
@ 2006-06-08 13:04 ` bonzini at gnu dot org
2006-06-08 15:24 ` sje at cup dot hp dot com
` (7 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: bonzini at gnu dot org @ 2006-06-08 13:04 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (12 preceding siblings ...)
2006-06-08 13:04 ` bonzini at gnu dot org
@ 2006-06-08 15:24 ` sje at cup dot hp dot com
2006-06-08 15:39 ` bonzini at gnu dot org
` (6 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: sje at cup dot hp dot com @ 2006-06-08 15:24 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (13 preceding siblings ...)
2006-06-08 15:24 ` sje at cup dot hp dot com
@ 2006-06-08 15:39 ` bonzini at gnu dot org
2006-06-08 15:50 ` bonzini at gcc dot gnu dot org
` (5 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: bonzini at gnu dot org @ 2006-06-08 15:39 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (14 preceding siblings ...)
2006-06-08 15:39 ` bonzini at gnu dot org
@ 2006-06-08 15:50 ` bonzini at gcc dot gnu dot org
2006-06-08 16:38 ` sje at cup dot hp dot com
` (4 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: bonzini at gcc dot gnu dot org @ 2006-06-08 15:50 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (15 preceding siblings ...)
2006-06-08 15:50 ` bonzini at gcc dot gnu dot org
@ 2006-06-08 16:38 ` sje at cup dot hp dot com
2006-06-11 15:43 ` [Bug middle-end/27733] [4.1 " soete dot joel at tiscali dot be
` (3 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: sje at cup dot hp dot com @ 2006-06-08 16:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (16 preceding siblings ...)
2006-06-08 16:38 ` sje at cup dot hp dot com
@ 2006-06-11 15:43 ` soete dot joel at tiscali dot be
2006-06-13 13:06 ` bonzini at gcc dot gnu dot org
` (2 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: soete dot joel at tiscali dot be @ 2006-06-11 15:43 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (17 preceding siblings ...)
2006-06-11 15:43 ` [Bug middle-end/27733] [4.1 " soete dot joel at tiscali dot be
@ 2006-06-13 13:06 ` bonzini at gcc dot gnu dot org
2006-06-13 13:12 ` bonzini at gnu dot org
2006-06-13 16:30 ` soete dot joel at tiscali dot be
20 siblings, 0 replies; 22+ messages in thread
From: bonzini at gcc dot gnu dot org @ 2006-06-13 13:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (18 preceding siblings ...)
2006-06-13 13:06 ` bonzini at gcc dot gnu dot org
@ 2006-06-13 13:12 ` bonzini at gnu dot org
2006-06-13 16:30 ` soete dot joel at tiscali dot be
20 siblings, 0 replies; 22+ messages in thread
From: bonzini at gnu dot org @ 2006-06-13 13:12 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug middle-end/27733] [4.1 Regression] Large compile time regression
2006-05-22 20:37 [Bug middle-end/27733] New: Large compile time regression danglin at gcc dot gnu dot org
` (19 preceding siblings ...)
2006-06-13 13:12 ` bonzini at gnu dot org
@ 2006-06-13 16:30 ` soete dot joel at tiscali dot be
20 siblings, 0 replies; 22+ messages in thread
From: soete dot joel at tiscali dot be @ 2006-06-13 16:30 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread