* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
@ 2007-05-07 1:33 ` pinskia at gcc dot gnu dot org
2007-05-08 20:18 ` sje at cup dot hp dot com
` (17 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-05-07 1:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-07 02:33 -------
It also uses up a lot of memory, 90% of 512 Megs.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |memory-hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
2007-05-07 1:33 ` [Bug target/31850] " pinskia at gcc dot gnu dot org
@ 2007-05-08 20:18 ` sje at cup dot hp dot com
2007-05-08 20:55 ` sje at cup dot hp dot com
` (16 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: sje at cup dot hp dot com @ 2007-05-08 20:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from sje at cup dot hp dot com 2007-05-08 21:18 -------
I am seeing this slow compile too. It compiles OK on HPPA in 32 bit mode (1.5
minutes) but takes over 30 minutes in 64 bit mode. It also takes 6+ minutes on
IA64 HP-UX. On an X86 box it took less than 1 minute.
Using gprof on HPPA 64 bit mode I see 2.6 Billion (2614726712) calls to
loc_mentioned_in_p. I think most are coming from remove_address_replacements
but I am still trying to understand the problem.
--
sje at cup dot hp dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
2007-05-07 1:33 ` [Bug target/31850] " pinskia at gcc dot gnu dot org
2007-05-08 20:18 ` sje at cup dot hp dot com
@ 2007-05-08 20:55 ` sje at cup dot hp dot com
2007-05-09 16:21 ` sje at cup dot hp dot com
` (15 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: sje at cup dot hp dot com @ 2007-05-08 20:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from sje at cup dot hp dot com 2007-05-08 21:55 -------
I now think the loc_mentioned_in_p calls are coming from the checking code at
the top of subst_reload. I commented out this checking code and my compile
speed up by more than 10X.
--
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 |2007-05-08 21:55:09
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (2 preceding siblings ...)
2007-05-08 20:55 ` sje at cup dot hp dot com
@ 2007-05-09 16:21 ` sje at cup dot hp dot com
2007-05-09 21:05 ` sje at cup dot hp dot com
` (14 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: sje at cup dot hp dot com @ 2007-05-09 16:21 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from sje at cup dot hp dot com 2007-05-09 17:21 -------
While testing my change (commenting out the checking code at the top of
subst_reload), I found that limits-fnargs.c sped up but I still get timeouts
for limits-fndefn.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (3 preceding siblings ...)
2007-05-09 16:21 ` sje at cup dot hp dot com
@ 2007-05-09 21:05 ` sje at cup dot hp dot com
2007-05-17 20:30 ` sje at gcc dot gnu dot org
` (13 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: sje at cup dot hp dot com @ 2007-05-09 21:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from sje at cup dot hp dot com 2007-05-09 22:05 -------
It looks like the slowdown in limits-fndefn.c is different than the slowdown
for limits-fnargs.c. The compilation time in limits-fndefn.c is spent in
push_to_sequence. The problem is that each (32 bit) argument is generating a
conversion operand (to 64 bits) and these conversions are getting put in
all->conversion_insns. Then we call push_to_sequence with
all->conversion_insns and each time we call it the list of instructions is
longer and push_to_sequence does a walk through the entire list each time it is
called, getting slower and slower and slower.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (4 preceding siblings ...)
2007-05-09 21:05 ` sje at cup dot hp dot com
@ 2007-05-17 20:30 ` sje at gcc dot gnu dot org
2007-06-07 16:46 ` sje at gcc dot gnu dot org
` (12 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: sje at gcc dot gnu dot org @ 2007-05-17 20:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from sje at gcc dot gnu dot org 2007-05-17 21:29 -------
Subject: Bug 31850
Author: sje
Date: Thu May 17 20:29:34 2007
New Revision: 124810
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124810
Log:
PR target/31850
* reload.c (subst_reloads): Remove checking.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reload.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (5 preceding siblings ...)
2007-05-17 20:30 ` sje at gcc dot gnu dot org
@ 2007-06-07 16:46 ` sje at gcc dot gnu dot org
2007-06-11 21:29 ` pinskia at gcc dot gnu dot org
` (11 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: sje at gcc dot gnu dot org @ 2007-06-07 16:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from sje at gcc dot gnu dot org 2007-06-07 16:46 -------
Subject: Bug 31850
Author: sje
Date: Thu Jun 7 16:46:26 2007
New Revision: 125532
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125532
Log:
PR target/31850
* rtl.h (push_to_sequence2): New.
* emit-rtl.c (push_to_sequence2): New.
* function.c (assign_parm_data_all): Add new fields.
(assign_parm_setup_block): Call push_to_sequence2 instead of
push_to_sequence.
(assign_parm_setup_reg): Ditto.
(assign_parm_setup_stack): Ditto.
(assign_parms_unsplit_complex): Ditto.
(assign_parms): Change field name.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/emit-rtl.c
trunk/gcc/function.c
trunk/gcc/rtl.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (6 preceding siblings ...)
2007-06-07 16:46 ` sje at gcc dot gnu dot org
@ 2007-06-11 21:29 ` pinskia at gcc dot gnu dot org
2008-11-18 7:37 ` tehila at il dot ibm dot com
` (10 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-06-11 21:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-11 21:28 -------
This testcase is still slow:
WARNING: program timed out. FAIL: gcc.c-torture/compile/limits-fnargs.c -O1
(test for excess errors)
WARNING: program timed out.
FAIL: gcc.c-torture/compile/limits-fnargs.c -O2 (test for excess errors)
WARNING: program timed out. FAIL: gcc.c-torture/compile/limits-fnargs.c -O3
-fomit-frame-pointer (test for excess errors) WARNING: program timed out.
FAIL: gcc.c-torture/compile/limits-fnargs.c -O3 -g (test for excess errors)
WARNING: program timed out.
FAIL: gcc.c-torture/compile/limits-fnargs.c -Os (test for excess errors)
I have not looked at why it is slow for spu-elf yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (7 preceding siblings ...)
2007-06-11 21:29 ` pinskia at gcc dot gnu dot org
@ 2008-11-18 7:37 ` tehila at il dot ibm dot com
2008-11-18 23:27 ` sje at cup dot hp dot com
` (9 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: tehila at il dot ibm dot com @ 2008-11-18 7:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from tehila at il dot ibm dot com 2008-11-18 07:35 -------
This testcase is indeed very slow on SPU, with -O2 and above.
I don't see any slowness for -O1.
If I turn off the insns scheduler (with -fno-schedule-insns) it is much faster:
X4 faster for 1,000 args (ARG3), much more for 10,000 args (ARG4).
It seems that the scheduler generates excessive register pressure, by hoisting
loads and sinking stores.
Maybe the "decision-maker" of the scheduler (which insn to move) should be
improved.
--
tehila at il dot ibm dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |uweigand at de dot ibm dot
| |com, bergner at vnet dot ibm
| |dot com, abel at ispras dot
| |ru, tehila at il dot ibm dot
| |com, zaks at il dot ibm dot
| |com, meissner at gcc dot gnu
| |dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (8 preceding siblings ...)
2008-11-18 7:37 ` tehila at il dot ibm dot com
@ 2008-11-18 23:27 ` sje at cup dot hp dot com
2008-11-25 12:19 ` tehila at il dot ibm dot com
` (8 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: sje at cup dot hp dot com @ 2008-11-18 23:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from sje at cup dot hp dot com 2008-11-18 23:25 -------
If you only get slow compilation at -O2 and above then your problem is probably
due to PR 37790. The original problem affected -O1 compiles as well as -O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (9 preceding siblings ...)
2008-11-18 23:27 ` sje at cup dot hp dot com
@ 2008-11-25 12:19 ` tehila at il dot ibm dot com
2008-11-25 14:29 ` abel at gcc dot gnu dot org
` (7 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: tehila at il dot ibm dot com @ 2008-11-25 12:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from tehila at il dot ibm dot com 2008-11-25 12:17 -------
(In reply to comment #10)
> If you only get slow compilation at -O2 and above then your problem is probably
> due to PR 37790. The original problem affected -O1 compiles as well as -O2.
PR 37790 doesn't solve the problem I see.
On SPU, with -O1 and -O2 -fno-schedule-insns the compilation time is long
(timed out == more than 5 minutes), but it's not as long as with -O2:
-O1 - 9.5 minutes.
-O2 -fno-schedule-insns - 10.5 minutes
-O2 - > 1000m
I don't know what can be done in order to improve compilation time on SPU, but
for sure - there is a problem in the insns shceduler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (10 preceding siblings ...)
2008-11-25 12:19 ` tehila at il dot ibm dot com
@ 2008-11-25 14:29 ` abel at gcc dot gnu dot org
2008-11-27 12:21 ` tehila at il dot ibm dot com
` (6 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: abel at gcc dot gnu dot org @ 2008-11-25 14:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from abel at gcc dot gnu dot org 2008-11-25 14:28 -------
I have somewhat cut the testcase, having the call with two ARG3's instead of
ten coming from ARG4. With this smaller testcase, I see that the most time is
taken by register renaming (cross to spu-elf, compiled with -O2):
scheduling : 0.66 ( 2%) usr 0.03 (30%) sys 0.69 ( 2%) wall
19208 kB (32%) ggc
integrated RA : 4.55 (11%) usr 0.00 ( 0%) sys 4.53 (11%) wall
829 kB ( 1%) ggc
reload : 2.57 ( 6%) usr 0.01 (10%) sys 2.58 ( 6%) wall
11996 kB (20%) ggc
reload CSE regs : 0.23 ( 1%) usr 0.00 ( 0%) sys 0.22 ( 1%) wall
2940 kB ( 5%) ggc
peephole 2 : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
0 kB ( 0%) ggc
rename registers : 32.21 (76%) usr 0.01 (10%) sys 32.22 (75%) wall
993 kB ( 2%) ggc
scheduling 2 : 0.58 ( 1%) usr 0.03 (30%) sys 0.61 ( 1%) wall
5375 kB ( 9%) ggc
machine dep reorg : 0.59 ( 1%) usr 0.01 (10%) sys 0.60 ( 1%) wall
5569 kB ( 9%) ggc
final : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall
0 kB ( 0%) ggc
TOTAL : 42.59 0.10 42.71
59919 kB
With -O2 -fno-rename-registers, I get
scheduling : 0.66 ( 6%) usr 0.04 (36%) sys 0.70 ( 7%) wall
19208 kB (33%) ggc
integrated RA : 4.56 (45%) usr 0.00 ( 0%) sys 4.57 (44%) wall
829 kB ( 1%) ggc
reload : 2.58 (25%) usr 0.00 ( 0%) sys 2.59 (25%) wall
11996 kB (21%) ggc
reload CSE regs : 0.23 ( 2%) usr 0.00 ( 0%) sys 0.24 ( 2%) wall
2940 kB ( 5%) ggc
thread pro- & epilogue: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
22 kB ( 0%) ggc
peephole 2 : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
0 kB ( 0%) ggc
rename registers : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall
0 kB ( 0%) ggc
scheduling 2 : 0.49 ( 5%) usr 0.04 (36%) sys 0.52 ( 5%) wall
4949 kB ( 9%) ggc
machine dep reorg : 0.50 ( 5%) usr 0.02 (18%) sys 0.51 ( 5%) wall
5055 kB ( 9%) ggc
reorder blocks : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
0 kB ( 0%) ggc
final : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall
0 kB ( 0%) ggc
TOTAL : 10.21 0.11 10.35
57732 kB
-frename-registers is enabled by default on spu, so no wonder this is not seen
on other targets.
oprofile shows me this:
Samples % linenr info image name app name
symbol name
-------------------------------------------------------------------------------
362678 29.6888 rtlanal.c:1412 cc1 cc1
note_stores
362678 100.000 rtlanal.c:1412 cc1 cc1
note_stores [self]
-------------------------------------------------------------------------------
304520 24.9280 regrename.c:1941 cc1 cc1
rest_of_handle_regrename
304520 99.8727 regrename.c:1941 cc1 cc1
rest_of_handle_regrename [self]
201 0.0659 bitmap.c:630 cc1 cc1
bitmap_set_bit
99 0.0325 df-scan.c:1217 cc1 cc1
df_insn_rescan
39 0.0128 df-problems.c:107 cc1 cc1
df_grow_bb_info
24 0.0079 (no location information) cc1 cc1
bitmap_clear_bit
17 0.0056 df-scan.c:573 cc1 cc1
df_grow_reg_info
8 0.0026 emit-rtl.c:1131 cc1 cc1
max_reg_num
-------------------------------------------------------------------------------
164550 13.4701 regrename.c:120 cc1 cc1
clear_dead_regs
164550 100.000 regrename.c:120 cc1 cc1
clear_dead_regs [self]
-------------------------------------------------------------------------------
6441 100.000 ira-color.c:1044 cc1 cc1
allocno_spill_priority_compare
59894 4.9029 ira-color.c:1044 cc1 cc1
allocno_spill_priority_compare
59894 86.6547 ira-color.c:1044 cc1 cc1
allocno_spill_priority_compare [self]
6441 9.3188 ira-color.c:1044 cc1 cc1
allocno_spill_priority_compare
1148 1.6609 splay-tree.c:348 cc1 cc1
splay_tree_remove
928 1.3426 splay-tree.c:139 cc1 cc1
splay_tree_splay
460 0.6655 ira-color.c:1083 cc1 cc1
splay_tree_free
247 0.3574 alloc-pool.c:325 cc1 cc1
pool_free
I don't have enough information to understand where note_stores calls come
from, and I stopped wondering for now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (11 preceding siblings ...)
2008-11-25 14:29 ` abel at gcc dot gnu dot org
@ 2008-11-27 12:21 ` tehila at il dot ibm dot com
2008-11-27 12:51 ` abel at gcc dot gnu dot org
` (5 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: tehila at il dot ibm dot com @ 2008-11-27 12:21 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from tehila at il dot ibm dot com 2008-11-27 12:20 -------
(In reply to comment #12)
Thanks, Andrey.
I think there are 2 "issues" here:
1. register-renaming. (more related to this PR, I think)
2. schuedule-insns.
Both of them slows compilation.
With ARG4, on SPU, I see:
-O1: 9m28.355s
-O1 -fno-rename-registers: 0m19.196s
-O2: 184m37.492s (not >1000 as I wrote, but >100)
-O2 -fno-rename-registers: 31m29.482s
-O2 -fno-schedule-insns: 10m26.851s
-O2 -fno-rename-registers -fno-schedule-insns: 0m39.425s
Should I open a different PR for scheduling?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (12 preceding siblings ...)
2008-11-27 12:21 ` tehila at il dot ibm dot com
@ 2008-11-27 12:51 ` abel at gcc dot gnu dot org
2008-11-27 12:59 ` tehila at il dot ibm dot com
` (4 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: abel at gcc dot gnu dot org @ 2008-11-27 12:51 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from abel at gcc dot gnu dot org 2008-11-27 12:50 -------
(In reply to comment #13)
> (In reply to comment #12)
> Thanks, Andrey.
> I think there are 2 "issues" here:
> 1. register-renaming. (more related to this PR, I think)
> 2. schuedule-insns.
> Both of them slows compilation.
> With ARG4, on SPU, I see:
> -O1: 9m28.355s
> -O1 -fno-rename-registers: 0m19.196s
> -O2: 184m37.492s (not >1000 as I wrote, but >100)
> -O2 -fno-rename-registers: 31m29.482s
> -O2 -fno-schedule-insns: 10m26.851s
> -O2 -fno-rename-registers -fno-schedule-insns: 0m39.425s
Do you see this on ppc to spu cross? How was your compiler configured? I will
try again with the full test case when you'll tell me your configure options.
(For my reduced test case, all scheduling was around 10% without register
renaming, as you can see from cc1 output, which is why I didn't look further
into this.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (13 preceding siblings ...)
2008-11-27 12:51 ` abel at gcc dot gnu dot org
@ 2008-11-27 12:59 ` tehila at il dot ibm dot com
2009-04-09 11:00 ` bonzini at gnu dot org
` (3 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: tehila at il dot ibm dot com @ 2008-11-27 12:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from tehila at il dot ibm dot com 2008-11-27 12:57 -------
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > Thanks, Andrey.
> > I think there are 2 "issues" here:
> > 1. register-renaming. (more related to this PR, I think)
> > 2. schuedule-insns.
> > Both of them slows compilation.
> > With ARG4, on SPU, I see:
> > -O1: 9m28.355s
> > -O1 -fno-rename-registers: 0m19.196s
> > -O2: 184m37.492s (not >1000 as I wrote, but >100)
> > -O2 -fno-rename-registers: 31m29.482s
> > -O2 -fno-schedule-insns: 10m26.851s
> > -O2 -fno-rename-registers -fno-schedule-insns: 0m39.425s
> Do you see this on ppc to spu cross? How was your compiler configured?
Yes (ppc(ppu) to spu cross).
Configuration:
--target=spu --disable-shared --disable-threads --disable-checking
--with-headers --with-newlib --with-system-zlib --enable-languages=c
--disable-nls --enable-version-specific-runtime-libs --disable-libssp
--program-prefix=spu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (14 preceding siblings ...)
2008-11-27 12:59 ` tehila at il dot ibm dot com
@ 2009-04-09 11:00 ` bonzini at gnu dot org
2010-07-30 23:14 ` pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
18 siblings, 0 replies; 21+ messages in thread
From: bonzini at gnu dot org @ 2009-04-09 11:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from bonzini at gnu dot org 2009-04-09 11:00 -------
On i686 to spu cross, for -O2 45 minutes were not enough.
--
bonzini at gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (15 preceding siblings ...)
2009-04-09 11:00 ` bonzini at gnu dot org
@ 2010-07-30 23:14 ` pinskia at gcc dot gnu dot org
2010-08-02 19:26 ` uweigand at gcc dot gnu dot org
2010-08-02 20:16 ` pinskia at gcc dot gnu dot org
18 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2010-07-30 23:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from pinskia at gcc dot gnu dot org 2010-07-30 23:13 -------
Someone might want to try this again after the fix for PR 38582.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (16 preceding siblings ...)
2010-07-30 23:14 ` pinskia at gcc dot gnu dot org
@ 2010-08-02 19:26 ` uweigand at gcc dot gnu dot org
2010-08-02 20:16 ` pinskia at gcc dot gnu dot org
18 siblings, 0 replies; 21+ messages in thread
From: uweigand at gcc dot gnu dot org @ 2010-08-02 19:26 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from uweigand at gcc dot gnu dot org 2010-08-02 19:25 -------
(In reply to comment #17)
> Someone might want to try this again after the fix for PR 38582.
It's a lot better, but still not real good. I'm now seeing on a QS22 (ppu ->
spu cross compiler):
-O0: 0m9.983s
-O1: 4m7.801s
-O2: 35m10.236s
-O3: 36m7.059s
However, the culprit clearly is no longer register renaming, which is now down
to 5 seconds in the worst case. For -O1, the by far slowest pass is dead store
elimination:
dead store elim1 : 101.02 (41%) usr 0.62 (35%) sys 101.65 (41%) wall
4307 kB ( 7%) ggc
dead store elim2 : 105.03 (43%) usr 0.65 (37%) sys 105.69 (43%) wall
3028 kB ( 5%) ggc
For -O2 and -O3, the by far slowest pass is register allocation:
integrated RA :1485.83 (71%) usr 15.86 (68%) sys1501.87 (71%) wall
2486 kB ( 2%) ggc
reload : 157.93 ( 8%) usr 1.97 ( 8%) sys 159.92 ( 8%) wall
30178 kB (19%) ggc
reload CSE regs : 100.05 ( 5%) usr 1.45 ( 6%) sys 101.51 ( 5%) wall
12556 kB ( 8%) ggc
Scheduling only takes about 2 min in either case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
2007-05-07 1:32 [Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf pinskia at gcc dot gnu dot org
` (17 preceding siblings ...)
2010-08-02 19:26 ` uweigand at gcc dot gnu dot org
@ 2010-08-02 20:16 ` pinskia at gcc dot gnu dot org
18 siblings, 0 replies; 21+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2010-08-02 20:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from pinskia at gcc dot gnu dot org 2010-08-02 20:16 -------
> reload CSE regs
Will most likely be helped by:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02397.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
^ permalink raw reply [flat|nested] 21+ messages in thread