[Bug target/31850] New: gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[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]

I get a timeout compiling gcc.c-torture/compile/limits-fnargs.c with -O1 and
above.  I think this is because SPU has so many register to pass to a function,
that it causes one RTL pass (most likely the register allocator) to go bonkers.


-- 
           Summary: gcc.c-torture/compile/limits-fnargs.c is slow at
                    compiling for spu-elf
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: compile-time-hog
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: spu-elf


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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[pinskia at gcc dot gnu dot org]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[sje at cup dot hp dot com]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[sje at cup dot hp dot com]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[sje at cup dot hp dot com]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[sje at cup dot hp dot com]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[sje at gcc dot gnu dot org]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[sje at gcc dot gnu dot org]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[pinskia at gcc dot gnu dot org]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[tehila at il dot ibm dot com]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[sje at cup dot hp dot com]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[tehila at il dot ibm dot com]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[abel at gcc dot gnu dot org]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[tehila at il dot ibm dot com]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[abel at gcc dot gnu dot org]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[tehila at il dot ibm dot com]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[bonzini at gnu dot org]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[pinskia at gcc dot gnu dot org]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[uweigand at gcc dot gnu dot org]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[pinskia at gcc dot gnu dot org]

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

[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |10.0
         Resolution|---                         |WONTFIX

--- Comment #20 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
SPU support was removed.